Path: utzoo!mnetor!uunet!husc6!think!ames!etl!hoey
From: hoey@etl.ARPA (Dan Hoey)
Newsgroups: comp.lang.lisp
Subject: Re: Compiling lexical closures
Message-ID: <51@etl.ARPA>
Date: 6 May 88 14:26:34 GMT
References: <304@utep-vaxa.UUCP> <23878@ucbvax.BERKELEY.EDU> <10734@steinmetz.ge.com>
Reply-To: hoey@etl.arpa (Dan Hoey)
Organization: USAETL, Fort Belvoir, Virginia
Lines: 32
Keywords: compile closures

In article <10734@steinmetz.ge.com> duff@eraserhead.UUCP (David A Duff) writes:
...
>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:
>...References to this environment will not be compiled correctly....
>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.

I think the key here is that the format of the environment for an interpreted
closure doesn't have to be the same as the format of the environment for a
compiled closure.  This works because in its usual operation, the compiler
compiles the environment for each bit of code it compiles.  So the job of an
implementor to deal with the special case would be to either

1) Convert the interpreter environment to a compiler environment on entry, and
    restore any changes on exit, or

2) Emit compiled code that can manage references to an interpreter environment.

Either choice would be a lot of work to implement a feature not required by
the Common Lisp specification.  The runtime overhead for choice 1 might well
exceed the gains made by compiling.  Choice 2 might require sweeping changes
throughout the code generator.

With the costs in mind, it is a lot easier to understand why ignoring this case
is a good idea.

Dan