Toplevel lexical variables

[VERACSD@A.ISI.EDU]

(let ((x 1))
  (defun f ()
    x))

     According to CLtL, it seems the above should work essentially
the same at top level as it would within a function definition with
(function (lambda ... )) in place of (defun ... ).
     The documentation for let (p. 111) says "each binding will be a
lexical binding unless there is a special declaration to the contrary
...  The bindings of the variables have lexical scope and indefinite
extent".
     The documentation for defun (p. 67) says "Evaluating a
defun form causes the symbol ... to be a global name for the function
specified by the lambda-expression ... defined in the lexical environment
in which the defun form was executed".
     However, neither Symbolics nor TI seems to allow this (I may not
have checked the very latest releases).

     Why would anyone want to use this?  Well, because it's there, because
it's (to my taste) cleaner and more elegant than using a global special
variable, and because it's good software engineering practice not to
have things accessible from where they're not intended to be accessed.
For a practical example, one might perhaps think of a login function using
a (computed) list of passwords.

     The compile function (p. 438) presumably ought to work the same way
(at least with the second argument supplied), although there isn't any
specific textual justification.  Symbolics and TI don't support this
either.

     Finally, if I may add a comment not about Common Lisp per se,
both Symbolics and TI fail to actually compile a defun within
a let, but make it a named-lambda instead (in addition to not scoping
it properly), when using c-sh-C from the editor, and probably do
the same when compiling and loading a file.  This is tolerated by
Common Lisp (defun is one of the top-level forms of which CLtL says
on p. 66 "Compilers, for example, may not recognize these forms properly
in other than top-level contexts"), but I would think that sophisticated
implementations should do the reasonable thing here.


Bob Sasseen