Re: Subverting 'Access for Sub-programs

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

In article
<Pine.BSF.4.10.9908052144260.14625-100000@shell5.ba.best.com>,
> It was probably the right choice at the time (1990-1995) to
> exclude downward funargs, and Robert Dewar's statement about
> the pain some implementor's would have suffered seems
> reasonable enough. It won't seem reasonable much longer
> though.

Indeed! And probably it is time for the ARG to address this
issue, and decide on an accepted language extension in this
area.

I am not sure that Unrestricted_Access (as defined by GNAT
for procedures) should be part of that proposal. Most certainly
you also want a "safe" version similar to what was proposed in
earlier mapping documents (the limited access to subprogram
feature).

Note that Unrestricted_Access in GNAT has three quite different
meanings:

1. For objects other than slices and unconstrained array types,
it provides a considerably nicer diction than taking the
'Address and converting the address to the required
access type by using unchecked conversion (a common Ada 83
diction). Since it adds no expressive capability, and is
obviously no implementation burden, this usage seems one that
would usefully be included in all Ada compilers.

2. For slice objects and unconstrained array type pointers, GNAT
permits capturing pointers to slices that "work", although there
are fairly subtle scoping restrictions. This very much depends
on the internal approach that GNAT uses for such pointers (the
so called "fat" pointers). It is not a usage that should be
encouraged, and certainly not one that should be standardized
at this time, since it would have far reaching implementation
impact in compilers other than GNAT. So this use of
Unrestricted_Access should definitely be considered to be
GNAT dependent (it can of course be VERY useful in some
situations, e.g. we have found it very useful for some work in
automatic translation of COBOL code).

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.

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.

Robert Dewar


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.