Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!elroy.jpl.nasa.gov!ucla-cs!uci-ics!zardoz!tgate!ka3ovk!drilex!axiom!linus!john From: john@linus.UUCP (John D. Burger) Newsgroups: comp.lang.lisp Subject: Re: CL and lexical closures Message-ID: <60981@linus.UUCP> Date: 28 Jul 89 22:51:36 GMT Reply-To: john@mitre.com Organization: The MITRE Corporation, Bedford MA Lines: 49 Interpreted LAMBDAs will normally result in lexical closures, even something stupid like (LAMBDA () 42) because there's no simple way to determine that no free variable access is going on. On the other hand, any good CL compiler should, as you say, only create a closure when there is such a free variable access. You might think that only the relevant bindings should be stored, but I think that usually the closure will simply point to the whole lexical environment. This is necessary when several closures share access to free variables, which they can use to communicate. Pointing to the whole environment can be avoided, but it's somewhat messy. As to your two examples, which I took the liberty of changing somewhat: (DEFUN STORE-FN-1 (SLOT-NAME) (SETF (GET SLOT-NAME 'LOOKUP-FN) #'(LAMBDA (OBJECT) (FOO OBJECT SLOT-NAME)))) (DEFUN STORE-FN-2 (SLOT-NAME) (SETF (GET SLOT-NAME 'LOOKUP-FN) (COMPILE NIL `(LAMBDA (OBJECT) (FOO OBJECT ',SLOT-NAME))))) Presumably, you're asking about the efficiency of the two internal functions, not the relative efficiency of STORE-FN-1 and STORE-FN-2. On most architectures, the result of STORE-FN-2 should be faster than STORE-FN-1, because the latter has to do a free variable access, while the former just pushes a constant onto the stack. Of course, STORE-FN-2 itself is SLOWER than STORE-FN-1, since it calls the compiler. -- John Burger john@mitre.org "You ever think about .signature files? I mean, do we really need them?" - alt.andy.rooney