Re: defvar affecting captured closure variables ?

Alex Mizrahi wrote:

seems pretty clear, but.. after you do perfectly legal (setf (symbol-value
'foo) 5), all implementations i know define FOO as some magical variable
-- it's not lexical or special, nevertheless it's definitely a variable,
since it's bound,

It's a dynamic variable, but it's neither special nor magical. According to
the CLHS[1] setting the symbol-value of a symbol will never signal an
error. So this should behave the same in any Common Lisp:

(setf (symbol-value 'foo) 42)
(boundp 'foo)
(symbol-value 'foo)

However, using the symbol as form is not well defined, but it still works:

(+ foo 32)

The relevant part of CLHS here is Symbols as Forms[2]. The symbol
is clearly not a symbol-macro, lexical variable or a constant. But is not a
dynamic variable either, since it's not declared special. Anyway it is
still threated as dynamic variable in most (or all?) implementations.

and indeed there are no complains from implementations
when such variables are used.

All the implementations I tested (CMUCL, SBCL, CLISP and ECL) will complain
if such code is compiled. Here is an example in ECL:

(defun bar () foo)
(compile 'bar)
;;; End of Pass 1.
;;; Compiling (LET* (# #) ...).
;;; The variable FOO is undefined.
;;; The compiler will assume this variable is a global.

Note that it does not matter if foo is bound or not when the function is
compiled. What matters is if it's declared special:

(defun bar () (declare (special foo)) foo)
(compile 'bar)
;;; End of Pass 1.

so, all implementations implement some "magical" kind of variables that
are not described by standard,

No, the variables are just completly normal dynamic variables. The "magic"
does not happen during (setf symbol-value), but when a symbol not declared
as special or a lexical variable is used as variable.

i believe that this means that all Common Lisp implementations are not
conformant to the Common Lisp standard.

I doubt it's a direct violation of the standard. At least I could not find a
requirement to signal an error if an undefined variable is used. Chapter does not mention the possibilty of undefined variables at all.

so, i wonder is there some rationale for introducing non-trivial
symbol-macro rules instead of legalizing behaviour that is already present
in all (most) implementations, and resolving many controversies at same

Because that behaviour is not what you really want. Silently threating
undefined variables as dynamic variables, will easly lead to hard to find
bugs. And as mentions above, compilers will warn you about this.