Re: Q: access to subprogram

[ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe)]

dewar@cs.nyu.edu (Robert Dewar) writes:

>  - if you use displays anyway, then the implementation is greatly 
>  - complicated. The maximum depth of the display is not known till
>  - link time, so either you take a huge hit in efficiency by using
>    some absurd maximum value (I have seen nesting depths well over
>    ten coming from the use of subunits), or you have to mess at
>    the linker level to determine the maximum, and then all data
>    structures that depend on this maximum become dynamcically sized
>    objects which must be dynamically allocated.

>It is this second concern about implementation difficulty that lead
>to the WG9 decision to restrict the feature so that such dynamic
>concerns would not be necessary, and also to ensure that the display
>model could be used without introducing undue overhead mentioned as
>the first concern above.

But (a) the maximum depth of the display is not *relevant* to the code
        generated for any procedure, with or without procedure parameters.
	The only depth that is relevant to any one procedure is the depth
	of that procedure itself
and (b) you don't know the maximum depth of the display until link time
        *anyway*.
So I still don't see what the problem is.  As for 10, that seems small to
me.  (The B6700 had 32 display registers, and there were actually Burroughs
customers who were rather upset when later models cut that back to 16.)
In any reasonable implementation of procedure parameters based on displays
(such as is necessary for Algol 60, Pascal, and PL/I) there is NO data
structure that cares the slightest tiniest little bit what the maximum
display size is, with the unique exception of the display itself.

>The distributed overhead argument did *not* enter into the discussion.

It did enter into _this_ discussion (thread).

>Basically the issue boiled down quite simply to a pragmatic issue. If
>the procedure pointers were made general, would this be too much of
>an implementation burden for existing implementations usinvg displays?
>And how does this balance against the increased utility?

We are agreed that there _is_ a burden, but we seem to disagree quite
a bit about what exactly that burden is.  Space-wise, it can be
	- N links in the parent of a passed-procedure
	- N links in the passed-procedure itself
	- 3N link assignments in a call
This is to provide the same level of support for procedure parameters
as Pascal; *not* the more general Algol 68 model which I have not been
talking about.

>Who knows, Richard, maybe you would have agreed to if
>you had listened to the detalied arguments (this was very extenisvely
>discussed) -- there were people there who felt as you do now when
>we started the discussion, but changed their minds.

I have found the Ada 9x design documents that I _have_ read (which comes
to a stack about 4 feet high) to be *extremely* interesting and valuable
for the field of language design.  If these detailed arguments have been
written up, I would be most interested to read them.

Basically, what I've read _here_ boils down to "People who designed Ada
implementations on the assumption that procedure calls are not
exceptionally important feared that providing a Pascal-like
procedure-related feature would be too expensive.", and it seems as if
either a much richer feature than I wanted (procedure _pointers_; I just
wanted procedure _parameters_) or a much dumber implementation than I
have in mind was envisaged.

>As to whether the decision is right in retrospect? hard to say. So far
>I have not seen any really convincing examples.

Self-fulfilling prophecy.  It's a better use of my time to figure out
how I _can_ accomplish something in Ada 95 (my favourite imperative
language) than to construct examples showing what I'd like to do and can't.
If I _were_ going to spend time on that, I'd explain why I would like to
be able to pass a generic procedure as a generic parameter (not an
*instance* of a generic procedure, the generic itself).

-- 
Fifty years of programming language research, and we end up with C++ ???
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.