From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,99ab4bb580fc34cd X-Google-Attributes: gid103376,public From: wolff@inf.fu-berlin.de (Thomas Wolff) Subject: Re: Q: access to subprogram Date: 1996/07/09 Message-ID: <4rud55$5b0@fu-berlin.de>#1/1 X-Deja-AN: 167440959 references: <4rb9dp$qe6@news1.delphi.com> <4re2ng$t7u@wdl1.wdl.loral.com> organization: Freie Universitaet Berlin x-access: 16 17 19 newsgroups: comp.lang.ada Date: 1996-07-09T00:00:00+00:00 List-Id: 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. 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.) : 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. Mark A Biggar: >>>Q: access to subprogram : In article jsa@organon.com (Jon S Anthony) wri tes : : : >In article 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. : 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. Compare my other response in this thread for remarks about the desirability of the discussed language feature. Thomas Wolff