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: ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) Subject: Re: Q: access to subprogram Date: 1996/07/19 Message-ID: <4snh9b$2tl@goanna.cs.rmit.edu.au>#1/1 X-Deja-AN: 169728172 references: <4rb9dp$qe6@news1.delphi.com> <4re2ng$t7u@wdl1.wdl.loral.com> <4rqbo9$b02@goanna.cs.rmit.edu.au> <4rvnbr$amu@goanna.cs.rmit.edu.au> organization: Comp Sci, RMIT, Melbourne, Australia nntp-posting-user: ok newsgroups: comp.lang.ada Date: 1996-07-19T00:00:00+00:00 List-Id: 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.