Modest proposal, 1 of 3

Modest proposal, 1 of 3

[Van Snyder]

BACKGROUND

Suppose procedure A contains B, but not C and D.  Suppose furthermore
that an access-to-procedure type T that is compatible with B is
visible to all three.  Notwithstanding the visibility, A is not
able to pass access-to-B to C as an argument.

The reason is that C might store its formal argument of type access-to-
procedure into a (relatively) global variable, and then D (or somebody
else) could use it to call B after its up-level environment (A's
local variables) disappears.

The crucial problem is the ability of C to store access-to-B into
a more global variable.  Absent that ability, it's a trivial exercise
in induction to show that B can only be invoked when its up-level
exists.

PROPOSAL for the next standardization of Ada

Allow the "limited" keyword as an argument-passing mode, similar to
"in".  The interpretation is that arguments of mode "limited" can only be used
to access something, or be bound as an actual argument to a formal argument of
"limited" mode.  In particular, as for other "limited" objects, assignment is
not defined.

Thus, one cannot store a copy of the argument into a more global
variable.

Then, allow access-to-procedure constants to be bound as actual
arguments to formal arguments of the appropriate type, but only
so long as the formal argument is of "limited" mode.
-- 
What fraction of Americans believe   |  Van Snyder
Wrestling is real and NASA is fake?  |  vsnyder@math.jpl.nasa.gov

Re: Modest proposal, 1 of 3

[Robert A Duff]

In article <572q86$g7m@netline-fddi.jpl.nasa.gov>,
Van Snyder <vsnyder@math.jpl.nasa.gov> wrote:
...
>Allow the "limited" keyword as an argument-passing mode, similar to
>"in". ...

During the Ada 9X project, this idea was proposed by the language design
team (except that "limited" was a property of the access-to-procedure
type, rather than being a mode), for exactly the reasons you suggest.
It was rejected primarily because the implementers didn't think it was
all that "modest".  This issue was discussed here at length some months
ago.

Note that limited access-to-object types would also be quite useful.

So where's numbers 2 and 3?

- Bob

Re: Modest proposal, 1 of 3

[Tucker Taft]

Van Snyder (vsnyder@math.jpl.nasa.gov) wrote:

: ...
: PROPOSAL for the next standardization of Ada

: Allow the "limited" keyword as an argument-passing mode, similar to
: "in".  The interpretation is that arguments of mode "limited" can only be used
: to access something, or be bound as an actual argument to a formal argument of
: "limited" mode.  In particular, as for other "limited" objects, assignment is
: not defined.

: Thus, one cannot store a copy of the argument into a more global
: variable.

: Then, allow access-to-procedure constants to be bound as actual
: arguments to formal arguments of the appropriate type, but only
: so long as the formal argument is of "limited" mode.

Actually, early in the Ada 9x process we did propose almost 
exactly this approach to handle passing non-assignable access
values, but at the time we were in a "downsizing" mode.  
They was also reconsidered right near the end, but again, they didn't
make the cut.  

One reason that they didn't make the cut is that they are 
fundamentally redundant with the notion of generic formal subprograms.
In fact, generic formal subprograms are somewhat more flexible, since one can
pass intrinsic operations such as Enum'Image as a generic formal
subprogram.  The downside is that generics generally imply macro-like 
code expansion (though not in all implementations).

The other reason these didn't make the cut is that they are a bit of
an implementation burden for implementations that use "displays"
rather than "static links" to support up-level references.

However, there were plenty of supporters for a feature like this,
and I'm sure it will be debated again every time changes to Ada are
considered.

: What fraction of Americans believe   |  Van Snyder
: Wrestling is real and NASA is fake?  |  vsnyder@math.jpl.nasa.gov

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA