From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 4 May 93 15:43:19 GMT
From: cis.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!howland.
reston.ans.net!noc.near.net!inmet!spock!stt@ucbvax.Berkeley.EDU  (Tucker Taft)
Subject: Re: Passing procedures as parameters to procedures.
Message-ID: <C6IEC8.M2F@inmet.camb.inmet.com>
List-Id: <comp.lang.ada>

In article <1993May4.102922.16895@sei.cmu.edu> 
firth@sei.cmu.edu (Robert Firth) writes:

>In article <C6I9J9.J9E@inmet.camb.inmet.com> 
stt@spock.camb.inmet.com (Tucker Taft) writes:

>. . . There are certainly languages where procedures
>>are first class objects, and can be freely assigned, passed around,
>>returned from functions, etc.  Such languages (e.g. Scheme) typically require
>>garbage collection, and the ability to have the activation record
>>for a subprogram on the heap.  
>
>Well, I've implemented three such languages, and none of them required
>garbage collection, activation records on the heap, or anything one
>tenth as complicated.  There is exactly one semantic problem with
>procedures as first class objects, and its the exact same problem as
>you have with variables as first class objects: references from more
>global entities to more local entities.  The usual simple solutions
>apply.  The simplest, and one made very easy by Ada's abstraction and
>packaging capability, is to rule that nested procedures are not first
>class.  Modula-2 has the same rule, and it made implementation of
>procedure values and variables very straightforward.

Unfortunately, in the example, the procedure was nested.
It is certainly true that if you only want un-nested
procedures to be "first class" then there is no problem.
Based on the example, I presumed the original questioner
was interested in a more general concept of "first class procedures."

Note, also, that the generic "contract" model interacts badly
with restrictions related to nesting.

In any case, I think Robert and I are in general agreement.
You can call these references "subprograms" or "access-to-subprograms,"
but if you want to avoid garbage collection, etc., you have to
live with some limitations on references to nested subprograms.

S. Tucker Taft  stt@inmet.com