From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: How to get Ada to ?cross the chasm?? Date: Sun, 6 May 2018 23:02:01 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <1c73f159-eae4-4ae7-a348-03964b007197@googlegroups.com> <87k1su7nag.fsf@nightsong.com> <87po2la2qt.fsf@nightsong.com> <87in8buttb.fsf@jacob-sparre.dk> <87wowqpowu.fsf@nightsong.com> <16406268-83df-4564-8855-9bd0fe9caac0@googlegroups.com> <87o9i2pkcr.fsf@nightsong.com> <87in88m43h.fsf@nightsong.com> <87efiuope8.fsf@nightsong.com> <87lgd1heva.fsf@nightsong.com> <87zi1gz3kl.fsf@nightsong.com> <878t8x7k1j.fsf@nightsong.com> NNTP-Posting-Host: kQkuQcRDy1QFvWpyB1foYw.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.8.3 Xref: reader02.eternal-september.org comp.lang.ada:52051 Date: 2018-05-06T23:02:01+02:00 List-Id: On 2018-05-06 21:27, Niklas Holsti wrote: >> "Applicative" is not a substantial property that hints any concrete >> implementation of publisher/subscribers bound through the data >> structure. If Ada should do anything, then provide much better support >> for user ADTs than it has now. > > An applicative data structure is a data structure that can be mutated > only by constructing what seems to be a modified copy of the entire > original data structure, but without actually copying most of the data, > and leaving the original data structure available unmodified. That is not a visible property the client may or should see. > In other words, a mutated version of the structure can be constructed > only by applying a function to the original version, with the function > returning the mutated version without harm to the original version. This is easily done in present Ada using handles to a reference-counted objects. The client copies a handle to the structure or its atomic part. So long it holds the handle its view remain intact. The writer overwrites the publicly visible handle with a new instance which has no effect on the client. When the client drops the handle the old version is collected (or not in some cases where memory is managed in a different way). > Such data structures tend to be based on "structure sharing" through > internal pointers that are not visible to the clients. In functional > languages with garbage collection these pointers are managed > automatically. In present Ada, the implementor of an applicative data > structure must manage the structure-sharing pointers explicitly, perhaps > with the help of controlled types. As I said it is quite easy and I used the described approach many times, e.g. for dealing with decision trees. > I don't know how to extend Ada to make applicative data structures > easier to implement in Ada. I have a few points. The key issues are: 1. Interface inheritance. The handle must have the same interface as the target object. It is tedious to write each time: type Node_Interface is interface; ... node operations type Node_Object is ... and Node_Interface with ...; type Node_Handle is ... and Node_Interface with null record; 2. Delegation. 2.a. Node_Handle must automatically delegate interface calls to its target. 2.b. Node_Handle interface calls might wish to take a mutex in the prologue and release it in the epilogue. Such trivial methods of composition must be supported. 3. Sane constructors and destructors 4. Sane user-defined aggregates 5. Parallel hierarchies handling 6. Sane handling of assignment, without controlled helper type kludges and access types. In particular, deference + update must be delegated to procedure and not split into two operations. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de