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 14:29:22 GMT
From: cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uwm.edu!spool.mu.edu!
howland.reston.ans.net!europa.eng.gtefsd.com!fs7.ece.cmu.edu!news.sei.cmu.edu!f
irth@ucbvax.Berkeley.EDU  (Robert Firth)
Subject: Re: Passing procedures as parameters to procedures.
Message-ID: <1993May4.102922.16895@sei.cmu.edu>
List-Id: <comp.lang.ada>

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

>One person's "implementation detail" is another person's "fundamental
>semantic model."  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.