Re: Subverting 'Access for Sub-programs

[Tucker Taft <stt@averstar.com>]

Robert Dewar wrote:
> ...
> 3. For subprograms, Unrestricted_Access provides a general
> mechanism corresponding really to what would more naturally
> be called Unchecked_Access, and to me the natural extension
> in the language would be to use Unchecked_Access for the
> purpose. I don't see any big semantic problem here. Pointers
> generated by the use of UA are the same as any other pointers
> generated by use of UA, namely you had better not use them
> when the corresponding referenced gizmo (be it an object as
> now allowed in the language, or a subprogram, as now forbidden)
> goes out of scope. The implementation impact is no worse than
> will be required for general downward funargs, so if you buy
> the latter, why not allow Unchecked_Access on subprograms as
> the natural extension.

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.

This reason hasn't changed, so I would still resist allowing
'Unchecked_Access to apply to subprograms unless we can agree
on a definition of where and when the values created by unchecked-access
can be used, independent of whether static links or displays are
used underneath.

One approach that helps is to require that a subprogram that is
to be subject to 'Unrestricted_Access, as well as the access-to-subp
type that is going to allow its use, be marked with some kind of
"pragma Unrestricted_Access" (analogous to marking an object with "aliased"
and marking general access types with "all").  This would prevent
distributed overhead for other subprograms/access-to-subp types.
> 
> I think that even if you implement the "safe" downward funargs
> features, you will still feel a need for UA on subprograms. The
> situations in which you need this are exactly similar to those
> which cause you to use UA for objects, e.g. you want to park
> pointers in some global structures, for later use, and you
> happen to know that your logic is such that they will not be
> used after the referenced gizmo has gone out of scope.
> 
> For example, I have a general library level procedure that does
> callbacks, and expects to be passed a record containing the
> stuff necessary for the callback processing, including an
> access-to-subprogram value. Currently I can't use a nested
> subprogram for that purpose which is annoying, and the "safe"
> proposal still won't allow it.

True, but you will need to come up with the display-based implementation
for this that doesn't incur distributed overhead for other
access-to-subp uses (which currently don't require any display
"fiddling" on call and can use single pointers for access-to-subp values).
I think a "pragma Unrestricted_Access" may be needed...

> Robert Dewar

-- 
-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