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.9 required=5.0 tests=BAYES_00 autolearn=ham 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: dewar@cs.nyu.edu (Robert Dewar) Subject: Re: Q: access to subprogram Date: 1996/07/10 Message-ID: X-Deja-AN: 168178052 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: Courant Institute of Mathematical Sciences newsgroups: comp.lang.ada Date: 1996-07-10T00:00:00+00:00 List-Id: "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 :-)