Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!utah-cs!utah-orion!shebs
From: shebs@utah-orion.UUCP (Stanley T. Shebs)
Newsgroups: comp.lang.lisp
Subject: Re: heapless evaluator... - (nf)
Message-ID: <166@utah-orion.UUCP>
Date: Tue, 30-Jun-87 11:15:10 EDT
Article-I.D.: utah-ori.166
Posted: Tue Jun 30 11:15:10 1987
Date-Received: Sat, 4-Jul-87 23:04:38 EDT
References: <6900004@iaoobelix.UUCP>
Reply-To: shebs@utah-orion.UUCP (Stanley T. Shebs)
Organization: PASS Research Group
Lines: 21

In article <6900004@iaoobelix.UUCP> wagner@iaoobelix.UUCP writes:

>Where is the closure object supposed to be located?? I reckon, the LISP system
>will put it onto the heap (stack is impossible due to its unknown lifetime)...

In general, a closure must be a distinct type of object that lives in the
heap.  It is normally a two-element structure, components are environment
and the code proper.  Of course, this can be extremely poor both space and
time-wise, so there are optimizations.  Environments can be shared or
eliminated in special cases, and if the closure can be proved to have a
bounded lifetime, as in the expression

(mapcar #'(lambda (foo) (* foo foo)) '(1 2 3))

then they can be stack-allocated.  See the Orbit paper in the 1986 Compiler
Conf proceedings for some good discussion of closure analysis.

>Juergen Wagner,		     (USENET) ...seismo!unido!iaoobel!wagner

							stan shebs
							shebs@cs.utah.edu