Re: Q: access to subprogram

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

Mark said

"If I remember right, it was felt that implementing "closures" (which is the
solution to this problem) placed an unacceptable distributed overhead
on programs that didn't use the feature.  Also I think that half the then
current Ada implementations were using "static links" and the other half
were using "displays" and implementing "clousers" would have been real
difficult for one of those groups (the "display" bunch I think)."

The displays issue was the real reason. Closures is a difficult term because
it means two totally different things, sometimes distinguished as upwards
closures (easy to do), and downwards closures (more complex, typically
requiring implicit heap allocation).

No one seriously suggested adding downward closures to Ada 95 (although
there is at least one person who loudly proclaims that this was a fatal
mistake and that Ada 95 is useless as a result -- of course you can
find such a person for almost any feature missing from the language :-)

During discussion of the subprogram pointer issue, the term closure was
often used, but in the more restricted ("upwards") sense, but this may
have caused some residual confusion.

(and just in case I give the wrong impression, I fully understand that
full closures, preferably in conjunction with partial parametrization of
higher order functions, lend tremendous expressive power -- for example
Ackerman's function can be written using primitive recursion if you have
these notions around), but I think the capability goes beyond the
appropriate semantic level for Ada -- no doubt that statement should 
set of a mini-thread :-)