Re: Q: access to subprogram

[rogoff@sccm.Stanford.EDU (Brian Rogoff)]

Magnus.Kempe@di.epfl.ch (Magnus Kempe) writes:
   ncohen@watson.ibm.com (Norman H. Cohen) writes:
   : 
   : Bill Taylor's contribution was part of an ongoing discussion in the form
   : of comments sent to the Mapping/Revision Team during the design of Ada 9X.

First of all, thanks Norman for that clear summary and the pointers. Is there 
a way I could have found out the location of these messages without asking you 
or reading all of the MRTcomments? It would be great if all of these 
arguments were webified and cross referenced so I could look up "closure" or 
something like it and find out the reasoning that went into the design of the 
feature.

On the down side, I have a bit more sympathy for the "contra-downward-closure" 
position than I did before :-). I still don't have a good sense of how much 
faster a display based implementation might be, if at all, and I doubt that 
anyone will be convinced without experiments.

   If I remember correctly, the final decision was based on arguments about
   displays (Dewar arguing against a more generalized 'Access), alternatives
   using generics and abstract types (Barnes arguing de facto against a more
   generalized 'Access), and the bad mistake made in Ada 83 (the lack
   of access to subprograms, as compared to C, Pascal, etc.).

I think that the efficiency argument, if correct, is a valid argument not to 
include the feature given the goals of Ada. The argument about alternatives is 
rather weak, since the alternatives are so clumsy. A similar discussion has 
been going on in the Java community, where it appears that full (upward) 
closures may be added in the near future. Of course you can simulate them 
with objects and interfaces, but that is a rather heavyweight mechanism.

   This is not the only decision that was made on the basis of some 
   implementors' fears rather than for the sake of Ada users.  For instance, 
   at some point in the revision process child units of generics were 
   rejected; the "solution" was a compromise so that some implementors would 
   not need to make any changes
   in their linking steps when updating their compiler from Ada 83 to Ada 95.
   The consequence is that not all non-generic hierarchies of packages can be
   turned into generic hierarchies (just adding "generic" doesn't work, e.g.
   if some child unit needs to "with" another child unit in the same 
   hierarchy).

Magnus, do you have a list of issues such as this one in which you feel that 
orthogonality and usability were traded for the comfort of a few implementors? 
I'd like to hear their arguments too of course.

   As Norm mentioned, most of these issues are documented in the "mrtcomments"
   available online.  I hope the designers of Ada 0Y (oh-why) will read these
   discussions carefully for the next revision--if there is one--so that they
   can make a list of the fallacious arguments that will no doubt pop up again.

Indeed. Also, I think Ada 0X is the way I'd refer to it, although I like your 
humorous jab :-)

I also don't like knocking Ada so much, since every ignoramus with a computer 
seems to think that Ada is awful. Paraphrasing Stroustrup, I think Ada 95 is 
the best C++ there is!

-- Brian