[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Closure, Null Lexical Env.



    Date: 9 Jun 86 17:35 PDT
    From: Miller.pa@Xerox.COM
    
    "(eval '#'(lambda (x y) ...) nil)" does seem to be the best (only?) way
    to express "closure over null lexical environment" in common-lisp.

NOT COMMON LISP. Eval does not take a second arg which is an environment.
(pg 323) furthermore, eval *always* uses the null lexical environment.

Your suggestion implies that eval should not be a function, 
but rather, a special-form or macro since the following are not equivalent:

(let ((x #'(lambda (x y) ...)))
  (eval x))

(eval #'(lambda (x y) ...))

which is surprising since 

(let ((x '(lambda (x y) ...)))
  (eval x))

(eval '(lambda (x y) ...)) 

are equivalent. In CL, eval is a function.  In (eval <form>),
eval doesn't even get called until <form> has been evaluated in the
current environment. It is only if <form> evaluates to a list
that issues of what environment eval uses can be relevant.
i.e.,

(flet ((foobar (x) (eval x)))
  ....
  (foobar #'(lambda (x y) ...)))

is entirely equivalent to (eval #'(lambda (x y) ...)).

If you want a lex-closure which has no lexical environment, then 
free non-special vars within it should never be touched or they'd
produce errors (unbound lexical var I guess).

What do you want to use this device for? I can only think of one
scenario, which is as an "end of scope" device, a la the language
Pebble. Pebble uses big moby function objects (read lexical closures)
as a modularization tool, similar in spirit to the use of
environments in scheme, and intended to solve "package" problems via
function composition. To detect errors in this modularization, they
provide a scope-ender construct, so that you can know that your
function isn't getting anything from outer lexical scopes.
(personally, I don't like Pebble, but the concept seems to apply
here).

Is there any other reason that you could possibly want this 
close-in-null-lexical-environment ???

mike beckerle
Gold Hill Computers
mike%gold-hill-acorn@mit-live-oak.arpa