Re: Passing procedures as parameters to procedures.

[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)]

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