Re: Depending on passing mechanism

[dewar@merv.cs.nyu.edu (Robert Dewar)]

Brian Rogoff  <bpr@shell5.ba.best.com> wrote:
>       The Ada flaws in Henry Bakers papers that I personally find
>just as annoying in (the non-concurrent subset of ) Ada 95 are
>
>       (1) No out mode in functions
>       (2) No ability to interleave public and private parts in
>           package specs
>       (3) No mutually recursion across package specs
>       (4) No "downward funargs" (fixed in GNAT with Unrestricted_Access
>           attribute)

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. Yes, it is true
  that Robert Dewar, and Bob Duff, and Brian as well disagree, but we
  are in a clear minority. Furthermore a significant section of the
  majority is VERY vocal on this issue. When the Ada 9X requirements
  were written, we included removing this restriction as an example
  of a possible restriction to be removed. The only reactions we got
  at all from the general list on the requirements were several violent
  reactions against this suggestion.

  When the matter was discussed several times in WG9, there was always
  a very strong majority against any change. So you may not like this,
  but it is pretty clear what people's taste is here.

  Note that in GNAT, we have implemented the Valued_Procedure pragmas
  from DEC Ada, which allow you to at least solve the most pressing
  case of this problem in connection with imported functions that
  have out parameters (you can even use this with convention Ada,
  but that would be a bit naughty).


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

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

  One thing to remember about CLA, is that most Ada programmers do not
  spend time reading it. The population of CLA is very heavily over-
  weighted with people who like to play with the language, and debate
  entertaining uses of abstractions, as opposed to people actually
  building large applications, who tend to have different concerns.

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

  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.

  Since major implementations did in fact use displays, and would have
  been significantly impacted by a decision that would require a change.
  In particular, the Alsys implementations (now Object Ada) would have
  been negatively impacted, and indeed it is interesting to note that
  there is no simple way for Object Ada to provide the equivalent
  of GNAT's Unrestricted_Access.

  Was this the right decision? Hard to say. Certainly GNAT uses static
  links anyway, since GNU C made this decision (after all C does most
  certainly have function pointers :-) But Object Ada could well have
  been significantly affected. Remember that the Ada 9X revision was
  already large enough to knock one major player out of the ring
  (as Bevin will tell you, the extent of the Ada 95 changes was a
  major factor in DEC's decision to withdraw from the Ada implementation
  arena).

  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.

Robert Dewar
Ada Core Technologies