Re: Q: access to subprogram

[jsa@organon.com (Jon S Anthony)]

In article <DuDyus.I8I.0.-s@inmet.camb.inmet.com> stt@henning.camb.inmet.com (Tucker Taft) writes:

> Jon S Anthony (jsa@organon.com) wrote:
> 
> : ... What's entertaining is that I
> : failed to make clear that it wasn't the actual leaving out of the
> : proposal that was "stupefying" but rather the purported reasons for
> : doing so.  
> 
>...[interesting stuff snipped]
>
> At the time of this original proposal (in 1990, I believe), the
> 9X reviewers were overwhelmed by the number of changes proposed for
> Ada 9X, and this just seemed like added complexity for less than
> comensurate gain.  This was always the hard question: does the added 
> functionality make up for the added complexity, and is the Ada 9X 
> "complexity" boat reaching the point of sinking completely?

Now, we are on to something.  This is the sort of analysis I was
hoping was lurking behind the decision, not this emphasis on all the
rubbish about static links vs. displays.


> We had to make a lot of hard decisions.  If you look only at the
> "margin", taking one decision at a time, you can very frequently
> convince yourself that just this one more feature would have been
> a good idea.  However, we were defintely struggling with the 
> "overloaded boat" problem.

Makes _perfect_ sense and is completely reasonable.


> It is also easy to say that you shouldn't worry about compiler
> implementation, but in fact, many of the problems of Ada 83 (and
> perhaps Algol 68, and other well-designed languages) were due to the
> pragmatic realities of getting a sufficient number of high-quality,
> fully-compliant compilers out the door in a reasonable time-frame.

This also definitely makes sense - again in the overall picture!
Sure, in an individual case you don't want to introduce some
wild-6-sigmas-out construct that noone has any experience with in
implementing.  But other than that, the overall goal (best overall
design which can actually be produced) should be primary.


> One of our goals was to minimize changes that required modifications
> to compiler back ends.  We achieved this goal to a remarkable extent,
> in my view.  Another sub-goal was to allow existing "C" compiler backends 
> to be used with Ada 95 front ends, without major changes to the backend.
> Support for downward closures clearly began to run afoul of this goal.

As several have pointed out, this is not particularly convincing.  The
best evidence indicates that this was a red-herring in this instance.


> Hence, we now have a suggested feature that:
> 
>    1) Adds semantic complexity (by requiring two kinds of 
>       access-to-subprogram types, limited and non-limited);
>    2) Is largely functionally redundant with an existing feature;
>    3) May require changes to many backends.

Wow!  Here's an analysis that really makes sense - especially in the
ranking (hopefully this was not accidental!)  Stir in the bits about
balancing the "total reasonable amount of things that can go in" and
weighing it against something else which is much more important and
would have to go if this one got in and _voila_, a perfectly
reasonable and probably even correct decision.


> Our main "competitors" in the language wars, C, C++, and now Java,
> have no support for this feature.  

Well, now we are back to irrelevant...


> I hope you will at least agree that the answer is not a trivially
> obvious "yes"...

Correct.  Thanks, Tucker, for explaining this and showing that the
thinking that I was hoping was lurking behind the decision was.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com