Re: Q: access to subprogram

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

"I am getting tired of insults"

Sorry, did not mean to insult you, but you seemed not to understand what
was being said, and now I understand why from your article.

The concern about distributed overhead is not that the new feature
per se generates distributed overhead. Yes of course it is trivially
true that if you are using displays, you only pay the penalty when
you actually use procedure pointers and procedure arguments. As you
point out, many real compilers have been written this way.

But then, rather than distributed overhead, if you take the approach of
using displays, you have two problems

  - you have greatly increased overhead when the feature is used. Enough
    increased overhead that almost certainly the proper design approach
    is to use static links instead.

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

The distributed overhead argument did *not* enter into the discussion.
The distributed overhead concern (as expressed in Steelman) comes from
a concern that in general static links are less efficient than displays.
So if the language is designed so that static links are the right choice,
then you have a distributed overhead. Of course this is an arguable
point, as you can see from the discussoin, not everyone accepts that
static links are less efficient than displays.

But anyway, your "mighty puzzlement" arises from a confusion on your part
as to the argument that was being made. No one at any point claimed that
implementing procedure pointers in the context of a display implementation
causes distributed overhead. As you point out, it does not, and everyone
agrees with this, and no one has claimed anything to the contrary, and as
I point out above, the distributed overhead argument did not enter into
the WG9 discussions substantially, except in the following sense. There
were people who said things like "well displays are a silly thing to use
in any case, so why on earth are we worrying about compilers that make
such a silly choice." And the discussion of the viabiliyt of displays
in general did come up in that context.

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?

Answering such questions is always difficult because it fundamentally
involves comparing apples and oranges. There is no doubt that it would
have resulted in a substantial implementation burden, and here is no
doubt that it would have been a useful feature. WG9 decided the former
had precedence. 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.

As to whether the decision is right in retrospect? hard to say. So far
I have not seen any really convincing examples. Perhaps some will appear.
Bob, it would be nice to post the original "safe" design here. Who knows
perhaps one day some extensions might be made to GNAT (certainly we are
seriously considering, and discussing with Tuck, implementing some variant
of his "with type" proposal to deal with the recursive type situation).
Note that any such extensions would of course be under a switch to
keep them under control :-)