Re: Depending on passing mechanism

[hbaker@netcom.com (Henry Baker)]

In article <dewar.877514974@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

> Interesting list. Let's look at them. 
> 
> (1) No out mode in functions
> 
>   This restriction is there because of a pretty clear consensus that it
>   would be a bad idea to allow out mode in functions.

The academics who wrote this into the original specifications for Ada
were more interested in doing research in _automatic_ software verification
than in actually programming real systems that did real things.  Their
research failed miserably, but we are left with their misguided attempts
to simplify their efforts in Ada.  You will notice that in other languages
where people actually had to get programs written and systems delivered,
this restriction has been dropped, mainly because of my previous posting --
that the language wasn't sophisticated enough to distinguish between
'benign'/'hidden' side-effects and not-so-hidden side-effects.

This is an example of a 'fascist' attitude for style over substance that
Dilbert gets so much mileage out of.

> (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 :-)\

As I have shown through examples before, this is not merely a stylistic
issue.  If it were, I would be much less adamant.  But through the various
non-orthogonal interactions of the features of Ada, you actually lose
significant expressive power.  This is another example of style over
substance.

> (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.

This is a most insidious restriction, because one spends a huge amount
of time performing very unnatural acts upon packages to try to get around
it.  It is a serious flaw, that reduces the amount of intelligence that
one can put into buttoned-up, prepackaged, off-the-shelf solutions for
others.

> (4) No "downward funargs" (fixed in GNAT with Unrestricted_Access
> attribute)

>   This was a quite different case. It arose from concern about existing
>   implementations using displays for implementing subprograms. It is
>   quite clear to me that in Ada 83, displays are definitely more efficient
>   than static links. This is because you only pay an overhead for calling
>   a subprogram that *contains* nested subprograms, rather than an 
>   overhead for calling a nested subprogram. The former is dyanamically
>   much less common than the latter.

You haven't seen 'lambda-lifting', have you.

>   Steelman in fact understood the efficiency gain to be obtained here,
>   and one of many reasons for Steelman prohibiting subprogram pointers
>   was to avoid inefficiencies in uplevel reference handling, since
>   Steelman correctly anticipates that nested subprograms would be
>   very common in Ada programs.

Ada people didn't listen to their critics in this case.  SRI and MIT evaluated
Ada and specifically pointed out this lack (in writing) as a serious problem
for large scale systems.  Without closures -- even downward closures -- you
can't do call-backs.  (They weren't called call-backs in the mid-1970's, but
they were extensively used, non-the-less.)