Re: Q: access to subprogram

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

Thomas Wolff said

  "To base design decisions for a language supposed to be an important one
   on compiler considerations is a very bad idea, I think! A shame that you
   lost that argument..."

You cannot really mean this as an absolute principle. All languages are
designed with some concern for implementability. A wonderful Ada 95 which
no one implemented would not be much use to anyone. Sure it is true that
any single feature will not make the difference (but that's what camels
and straws are all about).

You can argue that the decision was made wrong in this particular case,
but to say that as a general principle it is wrong to consider implementation
issues seems quite off base.

 : 1. Displays are too much trouble, in the presence of downward closures.
   No, you only need to find the right trick once. (How much trouble is
   "too much" anyway?)

It is not just that they are too much trouble, but that they are inefficient
for the purpose at hand (when procedure pointers are around). As to only
needing to find the right trick once, that's wrong. Complete solutions need
linker involvement, and that tends to mean finding the solution more than
once and fighting various linker capabilities. As to how much trouble is
"too much" that of course is central to the judgment of the trade off.

  Robert Dewar:
 : parameters in Pascal or Algol, if done right, clearly violates this, and
 : requires entire sections of displays to be saved and restored.
  But only for calls of formal procedures.

Yes, and calls of formal procedures are what we are talking about here!

  I do not quite understand your argument about who followed which design
  choice as I thought according to this discussion both Adas cannot pass
  procedure parameters.
  However, contradicting the feature with display implementation is not
  an inevitable consequence as has meanwhile been shown in this thread.

No, of course you can pass procedure parameters in Ada 95. You really
ought to look at the language feature here to see how the accessibility
restrictions work. You can have procedure pointers and procedures as
parameters in Ada 95, it is just that there are some limitations.
Obviously a careful understanding of the limitations is important in
judging how much functionality has been given up for implementation
concerns.

If you are assuming that Ada 95 completely eliminated procedure parameters,
then your understanding of this thread is a bit distorted, since that would
clearly have been totally unacceptable to everyone.

  This overhead would not have to be taken on every call as you say
  but only on calls of formal procedures. Don't you think this is acceptable?

I don't like the overhead, but could live with it. But in any case
that has nothing at all to do with the decision to exclude the
fully general solution, although it is true that calling a formal procedure
in Ada 95 does NOT require this overhead, even if you are using displays.
The issue was the difficulty of implementation, not the overhead. We
discussed this difficulty in considerable detail (with the implementors
involved), so we certainly had the information to understand what these
difficulties were.

  : In other words, the usual invariant for level N of a global display is
  : that it points to the most recent level N procedure on the dynamic
  : invocation scheme.
  This is just the way compilers have cheated, i. e. no correct implementation
  of the Algol semantics, said "most-recent" error.

Here I lose you technically. The invariant I give is EXACTLY the correct
one for Algol-60 semantics, and for Ada 83 and Ada 95 semantics. As I
noted it can be modified to make it more efficient by considering only
procedures which contain other procedures, but you seem to contest the
invariant I state above, and that I don't understand.

  By "almost *searching*" I meant that the chain has to be followed until
  the desired level is reached, thus having a few indirections per access.
  I would, however, not like the idea that a compiler's efficiency in
  a basic design question depends on optimization.

The idea of a compiler's efficiency depending on optimization does not
seem odd at all to me. Certainly your puzzlement that static chains
are widely used is perhaps explained by this difference. The fundamental
assumption that is made in choosing static links is the assumption that
compilers will successfully eliminate wasteful duplicate following
of the chain.


Ah, looking back, I think I see why you did not like my invariant, you
are assuming it is applied to a single global display, and that of course
is not possible with generalized procedure parameters, although it is
possible with the procedure parameters of Ada 95. OK, exactly so! You
need multiple displays if you have procedure parameters, and that is
the source of the unpleasant overhead.