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,2308afbbe4ecec0b X-Google-Attributes: gid103376,public From: Tucker Taft Subject: Re: Subverting 'Access for Sub-programs Date: 1999/08/11 Message-ID: <37B1A8B5.219C9FE6@averstar.com> X-Deja-AN: 511501435 Content-Transfer-Encoding: 7bit Sender: news@inmet.camb.inmet.com (USENET news) X-Nntp-Posting-Host: houdini.burl.averstar.com References: <37A71EF1.2201@dera.gov.uk> <37A7FDE8.4F5@dera.gov.uk> <7o9vrv$qgt$1@wanadoo.fr> <7oc5ih$6mb$1@wanadoo.fr> <7oejga$28i$1@nnrp1.deja.com> <37AEF7BF.7BBC8E06@averstar.com> <7oqahu$3s0$1@nnrp1.deja.com> Content-Type: text/plain; charset=us-ascii Organization: AverStar (formerly Intermetrics) Burlington, MA USA Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-08-11T00:00:00+00:00 List-Id: Robert Dewar wrote: > > In article <37AEF7BF.7BBC8E06@averstar.com>, > Tucker Taft wrote: > > The reason we didn't allow Unchecked_Access for subprograms > was > > that the definition of being "out of scope" depends on whether > > you are using static links or (per-task) displays. If you are > using > > static links, then a subprogram is out of scope if you have > exited the > > frame in which the subprogram was declared. For displays, the > subprogram > > is out of scope anyplace where you are not *lexically* > enclosed by > > the frame in which the subprogram is declared, because the > display > > (which is presumably *not* passed along with a > 'Unchecked_Access > > access-to-subprogram value) changes when you change the > *lexical* > > enclosing environment. > > You are missing the context here Tuck. Yes, we all understand > that the annoying restriction in the language comes from making > life easier for the display folks. I have explained this myself > many times. > > The discussion we were having is what should be done to the > language design if you abandon this annoying non-technical > consideration. > > It is in that context that I suggest that Unchecked_Access > would be appropriately allowed for subprograms with the > obvious semantics (if you absolutely *must* think in > implementation terms, the static link semantics that you > mention above :-) I understood the point about not worrying about "display" difficulties for *checked* language mechanisms. But for something called "Unchecked_Access" I have always presumed this is a mechanism that does the "obvious" thing, but just doesn't perform any legality checks. What you are proposing is that the "official" semantics for Unchecked_Access impose a requirement that it "work" whenever you are *dynamically* within the scope of the called routine. This implies a significant amount of mechanism on the part of display-based implementations to implement this, as opposed to simply eliminating the legality checks at the point of 'Unchecked_Access. In other words, *all* access-to-subp values might have been produced by 'Unchecked_Access, so *all* calls through such values in a display-based implementation must take that into account. By adding 'Unchecked_Access, you would be imposing a distributed overhead on all uses of access-to-subp values, even if there is no 'Unchecked_Access in the whole program, in the display-based implementation. *That* is why I wouldn't want to call this feature simply "Unchecked_Access." > ... > The predicate for this discussion is that we are assuming that > it is NOT reasonable to continue to walk around doing the design > with this ball-and-chain attached to our feet, and we are > wondering what the language should look like if we take a file > and cut it off :-) I can see forcing implementors using displays to support a more expensive mechanism under "new" circumstances, but I can't see dramatically slowing down all uses of existing access-to-subp values to support some additional feature. That kind of distributed overhead of a feature is quite unpleasant, especially as part of a language revision. We made major efforts during the Ada 9X process to minimize new features that imposed distributed overhead on old features. (We succeeded in most cases, though clearly exception handling is now more complicated given namable exception occurrences and finalization.) > > Yes, we probably want the limited-access types that are > completely safe, but I would also put in the Unchecked_Access > possibility, since it will cover additional useful cases. If we want an access-to-subp value that works any time you are still within the "dynamic" scope of a subprogram, I believe we should make it a different kind of access type. Perhaps type T is access all procedure ... ^^^ or some kind of pragma Unrestricted, or something. Even with the static link approach, supporting Unchecked_Access on access-to-subp values requires doubling the size of all "top-level" access-to-subp values, or using some sort of "trampoline" trick. Creating a trampoline that has the right lifetime is a fair amount of work as well, since the place of the 'Unchecked_Access is a bit late. I realize that GNAT has solved this, but I believe it takes significant advantage of work already performed as part of the GCC nested procedure support. And all this makes the 'Unchecked_Access a significantly more "heavyweight" feature than is implied by the name. It is far from being simply the moral equivalent of an unchecked-conversion. > Robert Dewar > Ada Core Technologies -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA