Re: Subverting 'Access for Sub-programs

[Robert Dewar <robert_dewar@my-deja.com>]

In article <37AEF7BF.7BBC8E06@averstar.com>,
  Tucker Taft <stt@averstar.com> 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.