Re: Q: access to subprogram

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

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

fallacious arguments on either side :-)

the same argument of implementability vs functionality will of course arise
if the language is revisited, and the view in either case may have changed.

On the one hand, implementors may come and say "well in retrospect that is
not such a big deal", or "Gosh, this was even more critical than we though
that this be left out because  xxx", and of course a different cast of
implementors and technologies will be around.

On the other hand, programmers may come and say "turns out that was not a 
critical feature after all, so it did not matter that we did not put it in",
or they may say "drat! I *really* find the lack of this feature a pain, and
it should be fixed now, here are some examples: xxx"

Different people will feel different ways (for example I find the lack of
in out and out parameters for functions a real pain, and suspect I will
continue to do so in the future, and that wasn't even left out befcause
of implementation concerns, but rather purity concerns).

One thing to notice is that once a feature is put *in*, then it never comes
out again, even if programmers arrive ten years from now and say "hmm,
we have found that feature useless, it can be removed". I find the
obsolescent features Annex in the Ada 95 a useless fantasy, when we
revise the language, we will still end up levaing these features in
because of compatibility concerns (remember what happened with COBOL 8X
and the attempt to remove ALTER).

Given that ratchet effect, one prefers to leave features out if you are
not absolutely sure they belong in!