[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Free variables in a LAMBDA which names a function
Re: This would be OK in a dynamically-scoped Lisp (in fact, I believe the
Maclisp compiler did exactly this), but not in Common Lisp. Your
definition should be equivalent to . . .
No, MacLisp never yanked internal lambda applications out of lexical
environment -- both it and Interlisp "did the right thing" in the
case of a function like:
(defun foo (arg)
((lambda (x) (+ x arg)) 5))
Probably you are remembering how both MacLisp and Interlisp would yank
an #'(lambda (x) ...) out of lexical context, and make it into a defun
with gensym'd name.
A point not sufficiently appreciated is that both MacLisp and Common
Lisp are *both* lexically and dynamically scoped. For MacLisp, you
will find that:
(1) had a bug in the interpreter in that local variables weren't
treated lexically, as they were by the compiler.
(2) couldn't handle lexical functions at all. [Note how "lexical
functions" differs from "lambda form applications"].
CLtL Chapter 3 is an excellent treatise on the issue of scope -- I
highly recommend re-reading it for anyone who hasn't done so recently.
(1) was a persistent misfeature of MacLisp, which everyone adjusted to
with some amount of grumbling. Interestingly, Interlisp considered (1)
to be a major feature, and its compiler was modified to match!
(2) was addressed by the Scheme papers. This, in fact, is probably
the most innovative feature of Common Lisp that didn't originate from
either MacLisp or ZetaLisp [although VAX/NIL made a stab at implementing
something like it]. Giving up any closure over dynamic variables was
an aggressive step back then. Full closure over the environment (both
lexical and dynamic) required "spaghetti stacks" -- see paper by Dan
Bobrow circa 1974. ZetaLisp and NIL had the notion of limited dynamic
closures, but these seemed to require "hard" implementation techniques
for limited advantage over simply "lexical closures".
-- JonL --