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!.POSTED!not-for-mail From: Bob Duff Newsgroups: comp.lang.ada Subject: Re: Ada design bug or GNAT bug? Date: Sat, 04 Jul 2015 10:05:27 -0400 Organization: A noiseless patient Spider Message-ID: <877fqgc920.fsf@theworld.com> References: <4lrj5zz2u2z.u8x9cf7xzic6.dlg@40tude.net> <58f64fa9-7d0b-44dd-870c-77d9afcb82c4@googlegroups.com> <4228c0ea-837d-42a0-b2a8-a98d8d30f820@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="fb59485c8ba9b0247fd521beeedcfecf"; logging-data="26957"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+Gbjv/tU3oD4sAw8HIbKY8" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:2SqV0A3PWdLbKnk+b9vVuF9wzsE= sha1:uj/ssfO47fd3YUysKkWCJm9oOfM= Xref: news.eternal-september.org comp.lang.ada:26613 Date: 2015-07-04T10:05:27-04:00 List-Id: "Randy Brukardt" writes: > 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). Yes, but I wish the dereference operator wasn't so big and ugly, not to mention illogical. I like Pascal's "X^". Then I'd disallow implicit dereference. >...Plus they > have weird dynamic accessibility semantics, which provides a tripping hazard > (as Bob Duff would call it) I didn't invent the term "tripping hazard". See here: https://www.google.com/search?q=tripping+hazard&client=ubuntu&hs=3p4&channel=fs&tbm=isch&imgil=SxoKW-zTjNggSM%253A%253Br37mO7FI_EoFRM%253Bhttp%25253A%25252F%25252Fblog.poolcenter.com%25252Farticle.aspx%25253Farticleid%2525253D6055&source=iu&pf=m&fir=SxoKW-zTjNggSM%253A%252Cr37mO7FI_EoFRM%252C_&biw=1855&bih=1105&usg=__-Q2E2qE_rVvTQOoxftNipyTyDkc%3D&ved=0CCoQyjc&ei=It-XVcm_Jce2sAXEl6mwDg#imgrc=SxoKW-zTjNggSM%3A&usg=__-Q2E2qE_rVvTQOoxftNipyTyDkc%3D One problem with those run-time accessibility checks is that there's no contract -- it's not clear whether the caller or the callee is supposed to ensure the check doesn't fail. The rules about by-copy vs. by-reference parameter passing have the same problem: When parameter passing might be by reference, is the caller supposed to avoid passing overlapping objects? Or is the callee supposed to avoid writing-then-reading that would cause trouble when overlapped? The language doesn't say. Most checks aren't like that. E.g. callers should ensure that preconditions are true, and callees should ensure that postconditions are true. Anonymous types would be OK if they didn't have special semantics -- they should just be a shorthand. And it's really weird that Ada 83 allowed some kinds of anonymous types (task, array) but not others (integer, record, ...). (Consistency?) And the array case has weird semantics. >... -- 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. Pretty much. > ... >>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. Yes, return by reference was a big mistake. The intention was to correct the mistake in Ada 83: function F return Some_Task is Local_Task : Some_Task; begin ... return Local_Task; which is an utterly useless thing to do. Build-in-place is a good idea -- too bad we didn't think of that 10 years sooner. >> -- 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). Ada pretends to support a compilation model where the compiler doesn't have to look at bodies when compiling clients. And the caller must know whether the callee is build-in-place. So triggering that via extended return wouldn't work. I say "pretends", because of generics and inlines. Randy's compiler manages to compile generic instantiations without looking at the body, but that requires heroics. A better language design would make that implementation natural (with the macro-expansion model being just an optimization). A compilation model with such a glaring exception isn't much use, IMHO, but I think ARG would like to keep up the pretense. (Generics are the glaring exception. Inlines don't bother me, because that's an optimization, and I can think of all sorts of optimizations that require looking at bodies. These days, gcc can do link-time optimizations.) >>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. :-) I could write a book on that. But Ada is still a much better design than many other languages I could name! - Bob