Re: Subverting 'Access for Sub-programs

[Tucker Taft <stt@averstar.com>]

Robert Dewar wrote:
> 
> 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 :-)

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