From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,2907a68906511623,start
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: Idea for Ada 200x: Arguments that are procedures
Date: 1998/07/02
Message-ID: <dewar.899428628@merv>#1/1
X-Deja-AN: 368270562
References: <6nh9f0$66i@netline.jpl.nasa.gov>
X-Complaints-To: usenet@news.nyu.edu
X-Trace: news.nyu.edu 899429018 8631 (None) 128.122.140.58
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1998-07-02T00:00:00+00:00
List-Id: <comp.lang.ada>


Van Snyder says

<<If an additional attribute were added to formal arguments to indicate
that taking a copy of a procedure pointer is prohibited, restrictions
on procedures that could be arguments could be reduced.

Since "limited" already puts restrictions on assignment, how about
using that word for the purpose of declaring a formal argument for
which it's prohibited to take a copy.  It could only be used to
access a procedure, or passed as an actual argument to a formal
argument that also had the "limited" attribute.

This would let me have, for example, a library package for quadrature
or minimization or differential equations or ... that exports a type
for a procedure pointer argument, and use a procedure that's internal
to my deep-in-the-guts-of-the-system procedure as the actual argument.
I can't do this now, because the type might outlive the procedure, and
therefore a pointer to the procedure might outlive its up-level.
>>


You are assuming that the restrictions in Ada 95 are because of possible
scoping and dangling reference problems. This is not the case, the limitations
are there to allow the use of displays in the implementation without a lot
of trouble. Alsys in particular argued very strongly that if the language
design made it hard for them to maintain the use of displays, that it would
be an unacceptable burden. This is actually one of the very few times that
the language got restricted very specifically because of a very specific
implementation approach. It is a bit ironic that in fact the old Alsys
technology died anyway (to be replaced by the Intermetrics front end). I
am not sure what other Ada 95 compilers actually do.

GNAT uses a static chain, and it is trivial from an implementation point of
view to eliminate the restrictions. Indeed the 'Unrestricted_Access
attribute in GNAT allows complete freedom in the use of procedure pointers,
but of course it is not protected against dangling pointers.

It is of course possible to design a safe feature along the lines that
Van Snyder suggests, and once again we are in the reinventing the wheel
mode. I would *strongly* suggest that before you get into the 
lets-add-this-feature to Ada, you look at the earlier mapping documents,
where many of the obvious ideas, including this one, have been explored
already.

Robert Dewar