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,29fe9a340e0d180d X-Google-Attributes: gid103376,public From: Brian Rogoff Subject: Re: Depending on passing mechanism Date: 1997/10/22 Message-ID: #1/1 X-Deja-AN: 285017832 References: X-Trace: 877562863 24875 bpr 206.184.139.132 Newsgroups: comp.lang.ada Date: 1997-10-22T00:00:00+00:00 List-Id: On 22 Oct 1997, Robert Dewar wrote: > Brian Rogoff wrote: > > The Ada flaws in Henry Bakers papers that I personally find > >just as annoying in (the non-concurrent subset of ) Ada 95 are ... deleted ... > > Interesting list. Let's look at them. ... deleted ... > (2) No ability to interleave public and private parts in > package specs > > Again, this is a very strong and intentional part of the design, for > which there has never been any consensus for change (though certainly > implementors would far prefer a style in which individual declarations > were marked private :-) Was it ever brought up, and violently reacted too? As was pointed out this restriction is a nuisance in Ada 95 in that it makes it clumsier to use generic signature packages. > (3) No mutually recursion across package specs > > Extensively discussed. As per these discussions, not such an easy > problem to solve, but Tuck's "with type" proposal is interesting. > As a point of interest, not one of our customers has even suggested > this as a desirable extension to GNAT, let alone suggested that they > would be willing to pay for it, so I wonder just how much it affects > things in practice. Your customers are probably clustered about some application domain, such as emdedded applications. I believe Tucker Taft said he started working on the "with type" stuff because of issues interfacing to Java. > (4) No "downward funargs" (fixed in GNAT with Unrestricted_Access > attribute) I'll note that after I read the arguments on this I agreed that omitting this was correct, though I am still annoyed. > As for Bob Duff's concerns about the inherent lack of safety in > Unrestricted_Access, I think in practice it is more theory than > practice. One tends to use Unrestricted_Access in very stylized > manners within abstractions where it is safe. We have not seen > one bug in our own code, or in customers code, from the use of > this attribute in GNAT. I'd prefer a standardized alternative, but I have no problem being tied to GNAT for now. As far as safety, I rather agree with Bob Duff but an unsafe implementation beats a safer proposal. :-) -- Brian