Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!snorkelwacker.mit.edu!ai-lab!zurich.ai.mit.edu!jinx From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas) Newsgroups: comp.lang.lisp Subject: Re: compiling lambda-CLOSUREs Message-ID: Date: 4 Apr 91 04:03:49 GMT References: <14172@medusa.cs.purdue.edu> <1991Apr3.095336.29725@hellgate.utah.edu> Sender: news@ai.mit.edu Reply-To: jinx@zurich.ai.mit.edu Organization: M.I.T. Artificial Intelligence Lab. Lines: 31 In-reply-to: moore%defmacro.utah.edu@cs.utah.edu's message of 3 Apr 91 16:53:36 GMT It should be obvious why compiling a closed "lambda expression" (as if there was any such thing) doesn't work; same reason that they can't be EVAL'ed. There are several problems that come up when compiling interpreted closures. The biggest one I can think of is dealing with the object that represents the closed-over environment. Normally, when compiling files, if the compiler encounters an object (such as an array), it can treat it as a constant and proceed. But in this case, not only is the environment object not constant, it has to be the same (i.e., EQ) object that was used in the interpreted function, because other functions may be closed over it too. It may be unreasonable to make the compiler deal with this special case. Also, compiled and interpreted code may use different representations of closed-over environments. In this case it would be impossible to compile an interpreted closure because other interpreted functions might be sharing the same environment. Although I understand why CL does not require this to work, the issues are not that hard to solve. The MIT Scheme compiler provides an entry point, COMPILE-PROCEDURE that given an interpreted closure will return a compiled closure that behaves the same way. Since MIT Scheme has first-class environments, we had to deal with the situation of mutable environments being shared between interpreted and compiled code, and directly manipulated by programs, and it is not hard to solve, but requires some care.