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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8b8748382fcfacc1 X-Google-Attributes: gid103376,public From: "Robert I. Eachus" Subject: Re: friend classes in ada95 Date: 2000/04/19 Message-ID: <38FE442C.92F7C2B3@earthlink.net>#1/1 X-Deja-AN: 613359873 Content-Transfer-Encoding: 7bit References: <38F6B617.34E216A7@emw.ericsson.se> <38F887AE.8CDA24E0@acm.org> <8dc8oi$kda$1@nnrp1.deja.com> <38FB8556.4EACD391@earthlink.net> <8dgk3m$aj7$1@nnrp1.deja.com> X-Accept-Language: en,pdf Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 956187704 63.24.55.244 (Wed, 19 Apr 2000 16:41:44 PDT) Organization: The MITRE Corporation MIME-Version: 1.0 NNTP-Posting-Date: Wed, 19 Apr 2000 16:41:44 PDT Newsgroups: comp.lang.ada Date: 2000-04-19T00:00:00+00:00 List-Id: Robert Dewar wrote: > Silly enough for you to have forgotten the issue :-) The issue > was whether to treat underscores as letters in identifiers, > removing the restrictions on the use of underscores. Actually > the example most often used was a trailing underscore, but the > general ability to mirror c identifiers such as a__b was also > an issue. As near as I can remember, the four alternatives discussed were: no change, allow trailing underscores, allow leading and trailing underscores, and treat underscore as if it was a letter. Since no concensus developed behind any change, the result was to stand pat. I personally think that the silliest part of this discussion ws on allowing leading underscores, and I think that was what killed the most general alternative. But all that is detail. > > IMHO, the changed to the treatment of abstract made at a later > > Boston meeting probably would not have been possible with the > > syntax proposed by Jean Ichbiah. > > That's plain wrong, or a misunderstanding, the notation > > class type x is record ... > > as simply a syntactic transformation of > > type x is tagged record ... > > is completely neutral with respect to such changes (indeed > an Ada 95 compiler today could if it liked accept the first > time as a source representation of the second form (though > this kind of stretching of the notion of source representation > is considered unsporting, even if allowed by the RM :-) The devil has always been in the details. If the only difference between Jean and Tucker's positions had been in the syntax, the online discussions would not have been anywhere near as long. In any case, the particular feature that I was referring to was to have an abstract formal private type and to derive another abstract type from it within the generic specification, and finally derive a non-abstract type from the instance: generic type Element is abstract tagged limited private; package Linked_Lists is type List_Element is abstract new Element with private; -- operations on lists... end Linked_Lists; ... package List_of_Strings is new Linked_Lists(Ada.Strings.Unbounded.Unbounded_String); type List_Element is new List_of_Strings.List_Element; This change made later, in Boston, required both syntax and semantic changes, and I felt that it fit extremely well with the tagged type grammar and semantics. I do not feel that it would have fit nearly as well with Jean's grammar, and would have required more semantic work. It was an extremely close call to even consider allowing the language design team to even work on this, although the vote the next day to adopt Tucker's proposal was overwhelming. The amount of compiler change was not an issue, but the amount of RM text to be changed was. Since this change was simplifying and unifying, it got in. Would a similar change to the class grammar have made it through? I don't know.