Re: Ada design bug or GNAT bug?

[Bob Duff <bobduff@theworld.com>]

"Randy Brukardt" <randy@rrsoftware.com> 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