Re: Q: access to subprogram

[bobduff@world.std.com (Robert A Duff)]

In article <4rud55$5b0@fu-berlin.de>,
Thomas Wolff <wolff@inf.fu-berlin.de> wrote:
>Robert Dewar: >>>Q: access to subprogram
> : Once you introduce unrestricted access to procedures, displays are a bit
> : of a menace, and probably this tips the scales in favor of static links
> : (if you believe like me that displays are more efficient, this can also
> : be read as meaning that the introduction of unrestricted access to procedures
> : would introduce distributed inefficiency -- but that still is NOT the reason
> : this feature was excluded).
>Why should displays be a menace where static links are not? Who would 
>actually prefer to really follow static links at all, effectively almost 
>*searching* for variables at run-time? Until now I thought this would 
>only be a theoretical concept and perhaps one of very early compilers.

Are you saying that static links are some sort of theoretical concept
from days-gone-by, and nowadays all smart compiler-writers use
displays?  Certainly not true.  I think *most* compiler-writers use
static links, just because it makes things simpler.  The horrible
"searching" you imagine is ameliorated by simple CSE elimination.  And
it's never terrible, since average nesting is approximately 0.01 levels
deep.

>Robert A Duff: >>>Q: access to subprogram
> : There are two major ways of implementing up-level variable references in
> : a language with nested procedures: Static links, and displays.  With
> : displays, it is somewhat difficult to implement passing nested
> : procedures as parameters, because you have to pass the display, which is
>This is not true, see below.
> : not of compile-time-known size.  Passing a static link is easy -- it's
> : just a single address.  Some implementations of Ada 83 used displays.
>Why not just push the display on the stack and pass its address??
>(If you really wanted to pass the display itself for some reason, you 
>could still use the program's maximal display size, wasting a few 
>bytes in these occasional cases.)

I agree -- it's not *that* big of a deal.  But "just push the display on
the stack" is an operation that involves compile-time-unknown-sized
stuff, which is where the complexity comes from.  And "use the max"
involves link-time knowledge, and most compilers (while very smart at
compile time) are very stupid at link time, and changing that fact
involves a lot of work.

> : The primary reason for not putting the feature in was to ease the pain
> : for such implementations.  This was done at a time when the general
> : feeling was that Ada 9X had more than enough new features, and we
> : shouldn't be adding things, but removing them.
>It is a very unfortunate decision to leave out a nice feature of 
>systematic program construction just for leaving out features.

Agreed.  But what's done is done.  (Until Ada 0X, or until you prefer
some other language.  ;-))

>Mark A Biggar: >>>Q: access to subprogram
> : In article <JSA.96Jul2221357@organon.com> jsa@organon.com (Jon S Anthony) wri
>tes
> : :
> : >In article <Dtxu2p.97F@world.std.com> bobduff@world.std.com (Robert A Duff) 
>wri
> : tes:
> : >> During the design of Ada 9X, we proposed a SAFE way of taking 'Access of
> : >> more-deeply-nesting subprograms.  To this day, I remain astonished and
> : >> sad that this particular feature didn't make it into Ada 95.  After
> : >> all, even Pascal has that feature!  And GNU C, which allows nested
> : >> functions (unlike standard C) allows this feature.
>I am sad about this, too. I have also always deplored that this 
>feature was removed during Wirth's transition from Pascal to Modula, 
>presumably for the same unconvincing reasons as used in this 
>discussion.

I was annoyed at that (about Modula-2) long before I joined the Ada 9X
project.  I think the real story is that there are two totally different
features, and both are desirable:

    1. You can pass procedures around, and copy them willy-nilly, and
       save them in global variables.  This is "call backs".  Pascal
       does not have this feature.  Modula-2 does, and Ada 95 does.

    2. You can pass procedures IN, and call them, but must never save
       them in global variables.  Pascal has this feature.  Modula-2
       does not.  Ada 95 does not, unless you count generic formal
       subprograms, which support MOST of this, but not quite all,
       and are overly verbose (IMHO).

Both of the above are desirable, but not at the same time.

Of course, the Smalltalk solution makes even Pascal's equivalent look
verbose.  And of course, I'm assuming in all of the above that "full
closures" are not supported (since they subsume all of the above, and
more, but require a totally different run-time model).

> : 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).
>No, with the solution indicated above there is no overhead (i. e. for 
>programs that don't use the feature) and no big inefficiency for programs 
>that do use the feature and no difficulty either apart from having to 
>understand what should happen in the implementation. When I recently 
>gave a talk on a topic related to this, some members of the audience 
>also seemed to recall they had the impression this was difficult or 
>inefficient... I wonder how this rumor evolved.

The "solution above" is viable, but is not the simplest solution.  The
simplest solution is to use static links.  (And that solution has the
desirably property that calling via an access-to-procedure will not
involve inordinate overhead.)

>Compare my other response in this thread for remarks about the 
>desirability of the discussed language feature.

Please understand that I'm arguing from two opposing points of view
here.  (1) I really think downward closures should have been included
in Ada 95, and (2) I'm trying to explain the arguments about why they
were not (which I disagree with, but are nonetheless rational
arguments).

- Bob