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!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Ada design bug or GNAT bug? Date: Fri, 3 Jul 2015 22:24:20 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <4lrj5zz2u2z.u8x9cf7xzic6.dlg@40tude.net> <58f64fa9-7d0b-44dd-870c-77d9afcb82c4@googlegroups.com> <4228c0ea-837d-42a0-b2a8-a98d8d30f820@googlegroups.com> NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1435980261 25813 24.196.82.226 (4 Jul 2015 03:24:21 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Sat, 4 Jul 2015 03:24:21 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:26599 Date: 2015-07-03T22:24:20-05:00 List-Id: "Shark8" wrote in message news:4228c0ea-837d-42a0-b2a8-a98d8d30f820@googlegroups.com... On Thursday, July 2, 2015 at 6:04:50 PM UTC-6, Randy Brukardt wrote: >> >> The reason Ada has anonymous access parameters was a desire (for Ada 9x) >> that code from existing OOP languages like C++ could be directly >> converted >> to Ada without having to think at all (thinking being necessary to get >> rid >> of access types). > >Do you think, in hindsight that (anonymous access parameters) was a >mistake? Surely. They were introduced mainly to solve two problems: the missing "in out" parameters for functions (and that they solved so imperfectly that Ada 2012 allows "in out" parameters for functions), and to allow dispatching on access types (something I'm dubious was necessary in the first place - dispatching on .all works in virtually all cases that I've seen). Plus they have weird dynamic accessibility semantics, which provides a tripping hazard (as Bob Duff would call it) -- an exception but only in unusual cases -- and a performance drain. "in out" has essentially the same semantics put without the hazard or performance issue. ... >I think I remember getting an error-message in GNAT awhile back >about return and reference semantics... wasn't that something that Ada95 >had but was later forbidden in Ada 2005? Because it was near-nonsense; you had to return a global variable -- but you should be avoiding global variables as much as possible, not requiring them. They had a few uses, but not enough to preserve. > -- Also, do you think it would have been better to have extended-return > signal to the compiler a desire for a build-in-place return-object? Probably not, build-in-place semantics isn't practical for all non-limited types (think normal assignment, can't build-in-place because if an exception occurs the original value has to be intact). > Also, I seem to recall your dislike of INTERFACEs -- in hindsight, what > would you have done differently if you needed the mechanism of > "Type T has functions X, Y, and X" applied to a group of types? > Generics, or some variations thereof? I wouldn't need such a mechanism. :-) I'm dubious of the value of that in the first place -- it's not zero, but it's close enough that it isn't worth hairing up a language or implementation to get it. >>> with P1; use P1; >>> package P2 is >>> type T3 is new T1 with private; >> private >>> type T3 is new T2 with null record; -- Legal! >> >>This is only legal because of a hack, which I was very much against >>introducing. If you have an extension component, this is illegal: >> >> type T4 is new T2 with record C : Character := '1'; end record; -- >> Illegal!!! >Why is this hack required?/How was it justified? How would you address the >problem w/o resorting to this hack? The thread that Dmitry and I have been having answers this question, and I don't want to spend time to repeat it. >Other than those specifics, I'm quite interested to know what you regard to >be mistakes in Ada's design. Someday I'm going to write a paper/blog post on that. But not today. I'd like to accomplish some work at some point in the month of July. :-) Randy.