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, MSGID_RANDY autolearn=no 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: Robert Dewar Subject: Re: Subverting 'Access for Sub-programs Date: 1999/08/10 Message-ID: <7oqahu$3s0$1@nnrp1.deja.com>#1/1 X-Deja-AN: 511213383 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> X-Http-Proxy: 1.0 x22.deja.com:80 (Squid/1.1.22) for client 205.232.38.14 Organization: Deja.com - Share what you know. Learn what you don't. X-Article-Creation-Date: Tue Aug 10 22:53:54 1999 GMT X-MyDeja-Info: XMYDJUIDrobert_dewar Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.04 [en] (OS/2; I) Date: 1999-08-10T00:00:00+00:00 List-Id: 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 :-) Yes, this would be annoying for the display folks, because, just as is necessary in Pascal if you use displays, you need to save the display as part of a subprogram access value. THis is not possible, but it is probably not the right approach. If you still agree that the non-technical arguments for making life easier for the display folks are operable, then of course you won't agree with this entire line of thought. 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 :-) 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. I would not go as far as the Unrestricted_Access semantics of GNAT for objects in any case as part of a semi-standard proposal since aspects of this (accesses-to-slices for example) are highly implementation dependent. What I was saying is that the diction in GNAT: subprog'Unrestricted_Access would more reasonably be called subprog'Unchecked_Access if we did not have an arbitrary rule in the current Ada standard forbidding us from allowing this. Actually we might well allow this with the -gnatX (extensions allowed) switch :-) Robert Dewar Ada Core Technologies P.S. just in case people get alarmed by the mention of -gnatX, the only extension currently there is the semi-respectable "with type" capability. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't.