Re: Future Ada language revisions?

[Robert A Duff <bobduff@world.std.com>]

vsnyder@vanpcjpl.nasa.gov (Van Snyder) writes:

> The reason that internal procedures can't be used for actual arguments seems
> to revolve around the possibility that their "addresses" might be copied,
> because when they appear as formal arguments they're "access to procedure"
> with no additional restrictions.  Right?

Right.

> Could we have another annotation for access formal arguments that prohibits
> using them for anything other than actual arguments, and dereferencing them?
> Say, "limited"?

The Ada 9X team proposed exactly that.  As an alternative, we also
proposed a set of rules that would allow copying, but not to a
more-global place.  Both of these proposals were rejected, primarily on
the grounds that they are hard to implement if the compiler uses a
"display" to implement a procedure's environment, rather than a "static
link".

I think it was a mistake.  I liked the "limited" idea best.  It matches
Pascal's semantics for passing procedures as parameters.  This is the
only case I can think of where Ada is less powerful than Pascal.

>...This would loosen up the restrictions on actual arguments
> that are procedures substantially.

Well, you would normally use one or the other.  There are really two
separate features here:

1. Call-backs.  The caller passes in a procedure that lives pretty-much
forever, and the callee can save it away in some global data structure.
This is supported by Ada 95.  It is often used in interfacing to things
like windowing systems.

2. Downward closures.  The caller passes in a possibly-local procedure,
and the caller is *not* allowed to save it in a global data structure.
This is not directly supported by Ada 95, although there are two
workarounds: (1) pass the procedure to a generic, and (2) pass a pointer
to a tagged type, where you have overridden the "do it" operation, and
the tagged type contains the procedure's environment.

Note that C supports 1, but not 2 (since C doesn't support nesting at
all, much less passing nested procedures as parameters).  Note also that
gcc supports both 1 and 2.  Interestingly, gcc uses neither of the
approaches I mentioned (displays or static links).  Instead, it uses a
"trampoline" mechanism, which involves writing machine code into the
stack, and passing around pointers to that machine code.  Self-modifying
code!  Also the gcc extension is unsafe, in that it allows dangling
pointers-to-functions.  The two Ada 9X proposals I mentioned above were
safe -- the "limited" proposal prevented copying of
pointers-to-procedures at compile time, and the other one checked at run
time that any copying could not create dangling pointers.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.