Re: Idea for Ada 200x: Arguments that are procedures

Re: Idea for Ada 200x: Arguments that are procedures

[Robert Dewar]

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

Re: Idea for Ada 200x: Arguments that are procedures

[Brian Rogoff]

Hmmm, where have I heard this before! Yes Van, this one is up on my list 
of "most wanted for Ada 0X" too. The desire for this construct was felt
during the Ada 9X design too, see 

http://sw-eng.falls-church.va.us/AdaIC/standards/95lsn/LSN1083.GeneralAccess

The reasons why it isn't in Ada 95 are well known. Hopefullly the same
excuse won't be used again, and implementors of display based Ada
compilation systems will be ready. Then Ada will be "almost functional"
:-)

-- Brian

On 3 Jul 1998, Van Snyder wrote:

> Procedures that are arguments are restricted in Ada because of the
> possibility of copying the pointer to somewhere that has a longer
> lifetime than the up-level environment of the procedure.
> 
> 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.
> 
> -- 
> What fraction of Americans believe   |  Van Snyder
> Wrestling is real and NASA is fake?  |  vsnyder@math.jpl.nasa.gov
> 
> 

Idea for Ada 200x: Arguments that are procedures

[Van Snyder]

Procedures that are arguments are restricted in Ada because of the
possibility of copying the pointer to somewhere that has a longer
lifetime than the up-level environment of the procedure.

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.

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

Re: Idea for Ada 200x: Arguments that are procedures

[Steve Whalen]

Van,

I'd vote for "fixing" this deficiency in the Ada200x version of the
language.  The way you suggested using "limited" for procedures as
parameters seems like a reasonable syntax to me.

Compared to GNAT's Unrestricted_Access attribute I would MUCH prefer
your approach because (to me) such attributes are way too powerful
(and implementation dependant).

This is about the only language issue I've seen raised on
comp.lang.ada that actually causes me problems in *my* "real world".
It seems silly to keep requiring workarounds for a deceased
implementation.

I hope you'll follow up on this with whomever one follows up with in
order to get this on the official list of things to add to Ada200x.

I couldn't find the old discussions of this particular issue in the
Mapping / Revision Team stuff, or the Language Study Notes.  However,
if there was no better reason for keeping this feature out of the
language than that implementations using displays would have problems,
I think this "fix" absolutely should make it into Ada200x.

Steve
-- 
{===--------------------------------------------------------------===}
                Steve Whalen     swhalen@netcom.com
{===--------------------------------------------------------------===}

Re: Idea for Ada 200x: Arguments that are procedures

[Brian Rogoff]

On Fri, 3 Jul 1998, Steve Whalen wrote:
> Van,
> 
> I'd vote for "fixing" this deficiency in the Ada200x version of the
> language.  The way you suggested using "limited" for procedures as
> parameters seems like a reasonable syntax to me.
> 
> Compared to GNAT's Unrestricted_Access attribute I would MUCH prefer
> your approach because (to me) such attributes are way too powerful
> (and implementation dependant).

I think you would agree with Robert Duff, who floated the limited access
type for procedure parameters a while ago, in 

http://sw-eng.falls-church.va.us/AdaIC/standards/95lsn/LSN1083.GeneralAccess

as I pointed out in my reply to Van Snyder. If you really want to go
digging, I've appended a post from Norman Cohen on this topic; you can use
the thread title to trace the entire thread under DejaNews. 

> This is about the only language issue I've seen raised on
> comp.lang.ada that actually causes me problems in *my* "real world".
> It seems silly to keep requiring workarounds for a deceased
> implementation.

I think more than one implementation uses displays, and there is also the
issue of problems caused in implementations with shared generics. 

FWIW, I started out with your view (omission of downward closures was an 
egregious mistake) and ended up agreeing that it was the only right thing
to do for Ada *95*. However, I have wanted this in code I write and I
think the workarounds are really clumsy and impair readability. I'd rather 
that generics were never shared, if the interaction of the two features
is problematic! 

I guess the thing to do is to ask your Ada compiler vendor to provide this 
feature in some form, so that even if we have N variants for N vendors at 
least the economic argument will be weakened.

-- Brian

From ncohen@watson.ibm.com Thu Jul 11 10:13:24 1996
From: ncohen@watson.ibm.com (Norman H. Cohen)
Newsgroups: comp.lang.ada
Subject: Re: Q: access to subprogram
Date: 11 Jul 1996 00:49:51 GMT
Organization: IBM T.J. Watson Research Center
Distribution: world
Reply-To: ncohen@watson.ibm.com
NNTP-Posting-Host: rios8.watson.ibm.com

In article <ROGOFF.96Jul8155205@sccm.Stanford.EDU>,
rogoff@sccm.Stanford.EDU
(Brian Rogoff) writes: 

|> ncohen@watson.ibm.com (Norman H. Cohen) writes: 
...
|>                            Bill Taylor had made what I considered an
|>    irrefutable case for downward closures, showing how much easier it
would
|>    be to write iterators if downward closures were allowed.  It came
down to
|>    a conflict between the interests of Ada programmers and the
interests of
|>    a minority of Ada implementors, and in this case the interests of
the few
|>    implementors using displays prevailed.)
|>
|> Could you summarize or provide a reference to Bill Taylor's work? Does
it
|> answer the objection that downward closures impose an inefficiency on
programs
|> that don't use them?

Bill Taylor's contribution was part of an ongoing discussion in the form
of comments sent to the Mapping/Revision Team during the design of Ada 9X.
All of these comments from June 1992 on are publicly available in the
following directory: 

ftp://sw-eng.falls-church.va.us/public/AdaIC/standards/95com/mrtcomments/

All the comments through April 1994 are in files with names of the form
YYMMmrt.zip, where YY and MM are the year and month the comment was
received.  (Thus all comments from May 1993 are in 9305mrt.zip.) Starting
with May 1994, there are individual daily files, such as 94.0501 for all
comments received on May 1, 1994.

The discussion on downward closures and their impact on display
implementations included the following comments: 

Date              Comment ID  Author          My summary

April 29, 1993    93.2622.b   Bill Taylor     The initial message about
                                              iterators mentioned above.

May 1, 1993       93-2628.b   Robert Duff     Says he likes the feature,
                                              but Robert Dewar has
                                              frightened WG9 members
                                              about the cost, and the MRT
                                              won't add downward closures
                                              until someone convinces WG9
                                              otherwise.  Claims the size
                                              of a display is not known
                                              at compile time.

May 3, 1993       93-2634.a   Norman Cohen    Reply to Duff, asserting
                                              that the size of a display
                                              IS known at compile time.
                                              Foreshadows an identical
                                              exchange that will take
                                              place on comp.lang.ada in
                                              July 1996.  :-)

May 3, 1993       93-2635.a   Robert Duff     Reply to Cohen.  Size of a
                                              display is not known at the
                                              site of a call through a
                                              pointer.  Says he hates
                                              arguing against a feature
                                              he likes.

May 3, 1993       93-2637.a   Randy Brukardt  Reports that Janus/Ada uses
                              (RR Software)   displays.  Proposes a
                                              workaround involving
                                              unchecked conversion.

May 3, 1993       93-2638.a   Robert Duff     Reply to Brukardt, asking
                                              him to explain workaround.

May 4, 1993       93-2644.a   Antoine Bertier Reports that Alsys uses
                              (Alsys)         displays for most of its
                                              compilers.

May 4, 1993       93-2645.a   Ted Baker       Calls displays an
                                              "anachronism", except on
                                              register-poor machines.

May 4, 1993       93-2646.a   Randy Brukardt  Reply to Duff, explaining
                                              his workaround and
                                              conceding that it is not
                                              portable to compilers that
                                              do NOT use displays.

May 5, 1993       93-2647.a   Brian Dobbing   Also reports that Alsys
                              (Alsys)         uses displays, states that
                                              Alsys cannot afford any
                                              more language changes with
                                              such great impact on their
                                              compilers, and states that
                                              neither the display
                                              approach nor the static
                                              link approach is always
                                              the right choice.

May 5, 1993       93-2651.a   Bill Taylor     Points out that Brukhardt's
                                              proposed workaround does
                                              not work when the pointed-
                                              to procedures reference
                                              data in surrounding scopes,
                                              as they do in his iterators
                                              example.

May 5, 1993       93-2655.a   Robert Dewar    Reply to Baker, defending
                                              displays and asserting
                                              that they can be quite
                                              efficient.

May 5, 1993       93-2656.a   Robert Eachus   Experiments (with a
                                              compiler that was altered
                                              to send Eachus e-mail every
                                              time code was generated for
                                              a call on a nested
                                              subprogram!) show that
                                              calls on nested procedure
                                              are rare, so the expense of
                                              supporting this feature is
                                              not justified.

May 6, 1993       93-2661.a   Ted Baker       Reply to Dewar, claiming
                                              that downward closures were
                                              important for the kind of
                                              applications that justified
                                              ANY inclusion of 'Access
                                              for nested subprograms in
                                              Ada 9X, and worth the cost;
                                              but admitting that Brian
                                              Dobbing's economic argument
                                              might be the deciding
                                              consideration.

May 11, 1993      93-2676.a   Randy Brukardt  Reply to Baker.

May 11, 1993      93-2676.b   Randy Brukardt  States that downward
                                              closures impose a
                                              distributed overhead on all
                                              uses of generics when
                                              generics are implemented by
                                              shared code for all
                                              instances, as in Janus/Ada.

January 14, 1994  94-3669.a   Bjorn Kallberg  An eloquent case for the
                                              importance of downward
                                              closures, pointing out that
                                              their omission would create
                                              the only case in which Ada
                                              is not a functional
                                              superset of Pascal.

February 15, 1994 LSN 1083    Robert Duff     A dispassionate analysis
                                              of all sides of the issue,
                                              explaining why the MRT
                                              decided not to include
                                              downward closures in Ada 9X.

March 4, 1994     94-3985.a   David Tombs     An empassioned plea to
                                              reconsider this decision.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Idea for Ada 200x: Arguments that are procedures

[Robert Dewar]

Steve says

<<I couldn't find the old discussions of this particular issue in the
Mapping / Revision Team stuff, or the Language Study Notes.  However,
if there was no better reason for keeping this feature out of the
language than that implementations using displays would have problems,
I think this "fix" absolutely should make it into Ada200x.
>>

There clearly will not be an anaologous development effort for Ada 200x
(compared to Ada 9X). FOr one thing the multi-million dollar funding
ncessary for such an approach is not there, and second, I don't think
anyone thinks it is appropriate at this stage.

Instead we can expect to see implementations introduce extensions that
are genuinely useful for Ada users on a gradual basis, and if and when it
is time for a new standard, it is more likely to be a ratification and
refinement of such existing extensions.

For example, the Size attribute, *particularly* in Ada 95, where the
situation has got worse due to some (in my opinion) injudicious choices
to be incompatible with most existing Ada 83 implementations, obviously
needs work. The Object_Size and Value_Size attributes in GNAT are 
essentially a proprosal in the direction of fixing this. Perhaps this
is not the best solution, but experimentation of this type is clearly
the right way to go in terms of implementing new features.

Of course this will tend to be driven by large serious users of Ada, but
that is as it should be. There are as in any language design a large
diverse collection of ideas from language enthusiasts (for example, there
are some who would go FAR beyond the limited access proposal, and insist
on full closures), but real users doing real applications are always a
somewhat more credible source of input on what the real problems are!

Re: Idea for Ada 200x: Arguments that are procedures

[Steve Whalen]

Brian Rogoff (bpr@shell5.ba.best.com) wrote:

: I think you would agree with Robert Duff, who floated the limited access
: type for procedure parameters a while ago, in 

: http://sw-eng.falls-church.va.us/AdaIC/standards/95lsn/LSN1083.GeneralAccess

: as I pointed out in my reply to Van Snyder. If you really want to go
: digging, I've appended a post from Norman Cohen on this topic; you can use
: the thread title to trace the entire thread under DejaNews. 

Thanks for the additional background.  I hadn't read the LSN1083 
note you referenced at the time I posted. Interesting history of
this "feature". 

Also interesting is the thread you attached, especially the note that
this is the only thing that keeps Ada95 from being a proper superset
of Pascal! I guess that's one reason that Ada95's lack of downward
closures feels so "wrong" to me.

: I think more than one implementation uses displays, and there is also the
: issue of problems caused in implementations with shared generics. 

: FWIW, I started out with your view (omission of downward closures was an 
: egregious mistake) and ended up agreeing that it was the only right thing
: to do for Ada *95*. However, I have wanted this in code I write and I
: think the workarounds are really clumsy and impair readability. I'd rather 
: that generics were never shared, if the interaction of the two features
: is problematic! 

I agree completely.  Either dump shared generics (because *I* don't
often/ever? need them <g>) or add another piece of programmer control
syntax to "limited" (maybe "limited controlled?") That way the programmer
can "promise" the compiler that the procedure pointer REALLY won't be
abused/confused and permit downward closure of procedure pointers.

The code that is needed to work around this "feature" is just TOO
UGLY!  It seriously detracts from Ada95's "elegance" and a main reason
for Ada's existance (if I wanted unreadable, difficult to maintain
code, I use C++ <g>).

Steve
-- 
{===--------------------------------------------------------------===}
                Steve Whalen     swhalen@netcom.com
{===--------------------------------------------------------------===}

Re: Idea for Ada 200x: Arguments that are procedures

[Charles Hixson]

Van Snyder wrote:
> 
> Procedures that are arguments are restricted in Ada because of the
> possibility of copying the pointer to somewhere that has a longer
> lifetime than the up-level environment of the procedure.
> 
	/*	snip	*/
> 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.
> 
> --
> What fraction of Americans believe   |  Van Snyder
> Wrestling is real and NASA is fake?  |  vsnyder@math.jpl.nasa.gov

I find the lack of a decent garbage collector to be a MUCH more
troublesome problem.  This is especially so as data allocated in library
units is not automatically freed during the program execution.  On the
other hand, it's VERY difficult to check that there are no dangling
references, so Unchecked_DeAllocation always feels very dangerous.  On
the third hand, Java's "lets garbage collect EVERYTHING" seems
excessive, and has GOT to be a part of what slows Java down.

This seems to be the kind of thing with so many possibilities and
internal dependancies that it is best dealt with by the compiler
writer.  And the memory leaks in various commercial applications
demonstrates very clearly how important an issue it is (i.e., enough so
that I prefer Java's approach to C++'s).

A second, and distinctly less important proposal, would be some way of
inserting common ancestors into a hierarchy, even it they needed to be
inserted as fully abstract classes.  Reorganizing the grouping of their
concepts (maps to hierarchies) is one of the important things that
people do, so I feel that the language should support it.  People don't
usually form a category until after they have collected several examples
that could fit into it.  And since programmers are people I expect that
others also keep having to reorganize their classes as time passes.

Re: Idea for Ada 200x: Arguments that are procedures

[Brian Rogoff]

On 3 Jul 1998, Robert Dewar wrote:
> There clearly will not be an anaologous development effort for Ada 200x
> (compared to Ada 9X). FOr one thing the multi-million dollar funding
> ncessary for such an approach is not there, and second, I don't think
> anyone thinks it is appropriate at this stage.
> 
> Instead we can expect to see implementations introduce extensions that
> are genuinely useful for Ada users on a gradual basis, and if and when it
> is time for a new standard, it is more likely to be a ratification and
> refinement of such existing extensions.

This is sensible. 

> Of course this will tend to be driven by large serious users of Ada, but
> that is as it should be. There are as in any language design a large
> diverse collection of ideas from language enthusiasts (for example, there
> are some who would go FAR beyond the limited access proposal, and insist
> on full closures), but real users doing real applications are always a
> somewhat more credible source of input on what the real problems are!

Hopefully small and medium users won't be ignored. In any case, the idea 
of integrating "full" closures into an Ada targetted for the JVM is not 
entirely absurd, since you have GC there anyways, much like you added 
Unrestricted_Access since gcc uses static links anyways. 

-- Brian

Re: Idea for Ada 200x: Arguments that are procedures

[Larry Kilgallen]

In article <swhalenEvJBCC.6Er@netcom.com>, swhalen@netcom.com (Steve Whalen) writes:

> I agree completely.  Either dump shared generics (because *I* don't
> often/ever? need them <g>) or add another piece of programmer control
> syntax to "limited" (maybe "limited controlled?") That way the programmer
> can "promise" the compiler that the procedure pointer REALLY won't be
> abused/confused and permit downward closure of procedure pointers.

I have not been following this, but I look to Ada for an environment
in which the programmer can "assert" but the compiler will verify.

I believe features where the programmer tells the compiler "trust me"
should have ugly names from the UNCHECKED_* series.

Larry Kilgallen

Re: Idea for Ada 200x: Arguments that are procedures

[Larry Kilgallen]

In article <359D41CE.D3976FA6@earthlink.net>, Charles Hixson <charleshixsn@earthlink.net> writes:
> Van Snyder wrote:
>> 
>> Procedures that are arguments are restricted in Ada because of the
>> possibility of copying the pointer to somewhere that has a longer
>> lifetime than the up-level environment of the procedure.
>> 
> 	/*	snip	*/
>> 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.

> I find the lack of a decent garbage collector to be a MUCH more
> troublesome problem.

So speak to your compiler vendor about garbage collection.
That does not seem to be a standards issue, and until there
are more Ada garbage collection implementations in use, it
would seem presumptuous to attempt to decide what constituted
a "decent" one.

Larry Kilgallen

Re: Idea for Ada 200x: Arguments that are procedures

[Dr Richard A. O'Keefe]

Charles Hixson wrote:
> references, so Unchecked_DeAllocation always feels very dangerous.  On
> the third hand, Java's "lets garbage collect EVERYTHING" seems
> excessive, and has GOT to be a part of what slows Java down.

Yes and no.  Java's object creation times (using Sun's JDK on a SPARC)
are _huge_ compared with other operations, and _way_ bigger than object
creation in for example Smalltalk, which also has quasi-parallel OOP.
One of the Erlang people pointed out to me that existing Java systems
have a single shared heap instead of a per-thread heap, so that object
creation has to involve locking, but that can't be the whole story.

Re: Idea for Ada 200x: Arguments that are procedures

[Robert I. Eachus]

In article <swhalenEvJBCC.6Er@netcom.com> swhalen@netcom.com (Steve Whalen) writes:

  > Also interesting is the thread you attached, especially the note that
  > this is the only thing that keeps Ada95 from being a proper superset
  > of Pascal! I guess that's one reason that Ada95's lack of downward
  > closures feels so "wrong" to me.

  Ada 83 and Ada 95 both support downward closures through use of
generics.  A few years ago I wrote some test programs not only to
verify that the language rules permitted it, but that the
implementations that used displays and/or shared generics got it
right.  At that time I talked to the implementors, in particular R&R
about how they implemented the feature, and found that, with a generic
instantiation, there is enough of a flag that something unusual is
happening that they didn't have to save and store contexts on every
procedure call, just when a generic is instantiated in an inner scope,
and the instantiation has a subprogram parameter, and that parameter
is from a nested scope.  Since the feature is "in there" for when it
is needed, I saw no reason to continue the fight for a simpler syntax.
(Jean Pierre Rosen was the first AFAIK to point out in an Ada 9X
context that generics could be used to implement downward closures, at
the meeting in Switzerland.  But there were Ada 83 validation tests
that required that it work there, so all compilers I tested
implemented it correctly.)
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Idea for Ada 200x: Arguments that are procedures

[Brian Rogoff]

On 7 Jul 1998, Robert I. Eachus wrote:
>   Ada 83 and Ada 95 both support downward closures through use of
> generics.

Don't you agree that the expression of programs which naturally use 
downward closures is clumsy with generics? I also question the performance 
impact of this "workaround". Richard O'Keefe had a very nice post last
time this came up in which he benchmarked a simple numerical integration 
routine in Ada, Pascal, Scheme, C, and Fortran, with the Ada using
generics and the Scheme (amongst others) using downward closures. The
Scheme compiler was able to do some impressive optimizations and ended up 
performing much better; more importantly, the Scheme code was much more
readable IMO than the Ada.
 
> Since the feature is "in there" for when it
> is needed, I saw no reason to continue the fight for a simpler syntax.

In the context of the 9X project, this was wise. Better to have a
good standard today, than a better one at some undetermined future date.
But this is definitely one of those things I hope gets fixed in a future 
language revision. 

-- Brian