From: John D. Burger
Subject: Re: CL and lexical closures
Date:
Message-ID: <60981@linus.UUCP>
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 ยทยทยทยท@mitre.org
"You ever think about .signature files? I mean, do we really need them?"
- alt.andy.rooney