' (lambda...)

[Hvatum@MIT-MULTICS.ARPA]

From: Steve Bacher (C.S.Draper Lab)
Subject: Evaluating '#'(lambda ...)
To: Miller.pa at XEROX.COM
cc: common-lisp at SU-AI
 
OK, let's say that you have an optimizing compiler that can take
function calls containing only constants and reduce them at compile
time.  This is effectively done by performing the operation at
compiler time and inserting the result into the compiled code,
n'est-ce pas?  Now, first of all the compiler needs a list of function
names for which it can perform this optimization (obviously CONS and
other side-effecting functions are not candidates).  Let us say that
EVAL is in this list.  Now, the way the compiler would handle a form
(EVAL 'FOO NIL) - assuming a slightly-uncommon-lisp EVAL that takes
a second argument for which NIL represents the null lexical
environment - is for the compiler to invoke EVAL on the constant FOO
in the lexical environment specified by NIL, and plug that value into
the code where the call to EVAL originally appeared.
 
Now, let's take the case of
 
   (eval '#'(lambda (x y) ...) nil)
 
The compiler will strip the quote mark off '#'(lambda (x y) ...)
and end up with (FUNCTION (LAMBDA (X Y) ...)), true?  Now, the compiler
then passes this form (a LIST whose CAR is the atom FUNCTION) to EVAL
and comes up with some object.
 
***********************************************************************
 
The nature of this object is what I was hoping to get some answers
to, since this seems unclear.  It has been flamed at great length
what #'FOO means where FOO is a symbol, but not what #'(LAMBDA (X Y)
(FOO X Y)) means.
 
***********************************************************************
 
Anyhow, as you may be able to see at this point, the implementation must
ALREADY have the capability (as implemented within EVAL itself) of
creating the correct kind of object to insert in the code at this point.
If it does, then there must be some way of creating it (which the
programmer ought to be able to get hands on).  Thus, we are back to the
original question.  If it does not, then there is no solution to the
problem in the given implementation, and the creation of
null-lexical-environment closures is not possible.
 
If EVAL of #'(lambda ...) does not return the same kind of object as
compiling #'(lambda ...), which I suspect it doesn't (or what would
be the difference between compilation and interpretation?), then
this would produce an unsatisfactory (to my mind) result - one might
as well code '(lambda ...).
 
But a further point is that it may not even be desirable to optimize
calls to EVAL.  After all, such an optimization would bypass a user
setting of *EVALHOOK*, for example.
 
                                        - SEB (at CSDL)