Path: utzoo!attcan!uunet!cs.utexas.edu!rutgers!aramis.rutgers.edu!atanasoff.rutgers.edu!lou From: lou@atanasoff.rutgers.edu (Lou Steinberg) Newsgroups: comp.lang.lisp Subject: Re: about EVAL Message-ID: Date: 8 Jun 90 13:16:25 GMT References: <200.266aae50@wsuiar.uucp> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 53 To: mnjafar@wsuiar.uucp In article <200.266aae50@wsuiar.uucp> mnjafar@wsuiar.uucp writes: > I looked in Guy Steele's book, but did not find an answer, > maybe I don't know where to look . What exactly is supposed to > happen when I issue an (eval '(setq i j)) inside a block ? See the definition of eval (p. 490 of 2nd edition of Steele): eval form The form is evaluated in the current lexical environment and a null lexical environment. The term "null lexical environment" means that the eval does NOT take place in the lexical scope where the eval appears. Thus, to simplify your example, (defun strange () (let (i j) (eval '(setq j i)))) is equivalent to (defun strange () (let (i j) (strange1))) (defun strange1 () (setq j i)) Note that the value of j your example code prints is for the binding INSIDE strange, which is unaffected by the setq of the top-level value done by the eval, and thus is still its initial value, NIL. I assume the language was defined this way because, in the general case, the form to be evaled may not be available until run time, but an efficient compiler may want to compile things in such a way that at runtime it is hard to figure out, e.g., that local variable i is currently being stored in register D3. Without this information, of course, the code to be evaled could not be properly interpretted (or compiled). Yes, this information could be kept somewhere, but the question is whether this kind of runtime access to the lexical environment would be worth the overhead needed to provide it. So, by your tests, Golden Common Lisp Version 1.01 is not a correct implementation of lexical scoping. (This may have been corrected in later versions.) The results returned by the other two implementations are correct. -- Lou Steinberg uucp: {pretty much any major site}!rutgers!aramis.rutgers.edu!lou arpa: lou@cs.rutgers.edu