Free variables in a LAMBDA which names a function

[edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)]

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 --