Newsgroups: comp.lang.lisp
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!defmacro.utah.edu!moore
From: moore%defmacro.utah.edu@cs.utah.edu (Tim Moore)
Subject: Re: compiling lambda-CLOSUREs
Date: 10 Apr 91 10:16:37 MDT
Message-ID: <1991Apr10.101637.18497@hellgate.utah.edu>
Keywords: was monitoring functions
Organization: University of Utah CS Dept
References: <14172@medusa.cs.purdue.edu> <1991Apr3.095336.29725@hellgate.utah.edu> <4448@skye.ed.ac.uk>

In article <4448@skye.ed.ac.uk> jeff@aiai.UUCP (Jeff Dalton) writes:
>In article <1991Apr3.095336.29725@hellgate.utah.edu> moore%defmacro.utah.edu@cs.utah.edu (Tim Moore) writes:
>>
>>"It is an error if the function to be compiled was defined
>>interpretively in a non-null lexical environment. (An implementation
>>is free to extend the behavior of COMPILE to compile such functions
>>properly, but portable programs may not depend on this capability.)"
>>
>>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. 
>
>I don't quite understand the point about EVAL.  The original question
>talked about a "lambda-closure", which is presumably what you get as
>the value of (FUNCTION (LAMBDA ...)) in some Common Lisp.  Indeed, in
>KCL you will get a list (LAMBDA-CLOSURE ...).  [That sort of result
>isn't allowed in CLtL II, where functions are supposed to be distinct
>from lists, but it's allowed in CLtL I.]

I brought up "closed lambda expression", i.e. a lambda expression with
free variables (not (FUNCTION (LAMBDA ...)), just (LAMBDA ...)), to
cover all bases. There seemed to be some confusion about terminology.

>
>>[Tim said the compiler may have trouble dealing with shared environments]
>
>I think this is right except for a few details.
>
>When compiling a file, the compiler or loader can cause constants to
>be "coalesced" (see section 25.1.4 Similarity of Constants, and
>especially page 694, in CLtL II).  However, COMPILE is not allowed to
>do this.  An object referred to as a constant by the compiled code has
>to be the same (in this case EQL) object referred to by the code
>before it was compiled (see CLtL II, page 115).
>
>Consequently, if an environment were an object, it's arguable that it
>would be the usual case for COMPILE to make the compiled function use
>the same one as the interpreted function, not a special case.
>

You are correct. Just because our compiler is broken in this case
doesn't mean everyone's is :-)

-- 
Tim Moore                    moore@cs.utah.edu {bellcore,hplabs}!utah-cs!moore
"Ah, youth. Ah, statute of limitations."
		-John Waters