Re: Q: access to subprogram

[stt@henning.camb.inmet.com (Tucker Taft)]

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.  

It is generally impossible to fully reconstruct the process by which
decisions like this are made.

But I will give it a try...

We originally proposed a version of access-to-subprograms that would
allow for downward closures.  These were called "limited access types"
because allowing assignment for these types would definitely create
the possibility for dangling references.  So these kinds of access
types would need to disallow assignment, and hence be "limited."

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?

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.

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.

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.

Finally, there was already very flexible support for downward closures
in the form of generic formal subprograms.  Admittedly, generics are
more verbose.  However, they don't have any of the limitations that
would likely be associated with an access-to-subprogram approach.  You
can pass a predefined operator, an attribute, even an enumeration literal
as a subprogram parameter to a generic.

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.

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

Is this the feature we should spend our valuable Ada 9X "chips" on?

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

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

: 617.484.3383
: jsa@organon.com

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA