Path: utzoo!mnetor!uunet!steinmetz!eraserhead!duff
From: duff@eraserhead.steinmetz (David A Duff)
Newsgroups: comp.lang.lisp
Subject: Re: Compiling lexical closures
Message-ID: <10734@steinmetz.ge.com>
Date: 5 May 88 16:08:14 GMT
References: <304@utep-vaxa.UUCP> <23878@ucbvax.BERKELEY.EDU>
Sender: news@steinmetz.ge.com
Reply-To: duff@eraserhead.UUCP (David A Duff)
Organization: General Electric CRD, Schenectady, NY
Lines: 35
Keywords: compile closures

In article <23878@ucbvax.BERKELEY.EDU> cox@renoir.Berkeley.EDU.UUCP (Charles A. Cox) writes:
>In article <304@utep-vaxa.UUCP> bernat@utep-vaxa.UUCP (Dr. Bernat ) writes:
>>I am trying to compile a lexical closure in Franz Common LISP ...

>   [...]
>
>If you want compiled closures, the correct thing to do is to compile
>the function which creates the closures, as this will cause all
>closures created to be compiled.

FYI: 

In lucid common lisp, compiling the function that generates the closure will,
indeed, cause the function to generate a compiled closure.  Also, if you try
to just compile a closure by itself e.g. (compile nil (return-a-closure)), you
get the following message:

(compile nil (return-a-closure))
#<Interpreted-Function (LAMBDA (X) (PRINT X)) 7E26F7> has a non-empty lexical environment.
References to this environment will not be compiled correctly.
Do you wish to try compiling #<Interpreted-Function (LAMBDA (X) (PRINT X)) 7E26F7> anyway? (Y or N): y

#<Compiled-Function 7E3357>

Offhand, I can't see any reason why a compile shouldn't be able to do this
correctly, since the closure obviously must have a pointer to the the
environment that was in effect at the time that it was created.  I assume that
it was just a special case that the implementors chose to ignore.

Dave Duff       
GE Research and Development Center
Schenectady, New York   518-387-5649

Note: in case default return address doesn't work try one of:
duffd@ge-crd.ARPA                 uunet!steinmetz!eraserhead!duff