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: 167758437 references: <4rb9dp$qe6@news1.delphi.com> <4rud55$5b0@fu-berlin.de> <4rvo07$bbl@goanna.cs.rmit.edu.au> <4s0qm7$htm@fu-berlin.de> organization: Courant Institute of Mathematical Sciences newsgroups: comp.lang.ada Date: 1996-07-10T00:00:00+00:00 List-Id: 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.