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)
42
(boundp 'foo)
T
(symbol-value 'foo)
42

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

(+ foo 32)
74

The relevant part of CLHS here is 3.1.2.1.1 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)
BAR
(bar)
42
(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)
BAR
(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
3.1.2.1.1 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
time?

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.


[1] http://www.lispworks.com/documentation/HyperSpec/Body/f_symb_5.htm
[2] http://www.lispworks.com/documentation/HyperSpec/Body/03_abaa.htm
.



Relevant Pages

  • Re: defvar affecting captured closure variables ?
    ... CG-USER: foo ... The standard is silent to allow implementations to experiment ... with possible things here, like global lexicals by default, or by warnings ... or by making globals default to specials ...
    (comp.lang.lisp)
  • Re: (read-from-string "#.(values) 42")
    ... represented by foo. ... I take this to mean that the reader macro function for the #. ... Not so simple, if 3 of the 6 implementations I tested, including ... "We're trying to find what the standard mandates or wanted to mandate ...
    (comp.lang.lisp)
  • Re: compiled local function in non-null lexical environment?
    ... > I think there is no portable way to do this, because in some implementations ... > the COMPILE function barfs when you give it an interpreted function which was ... > created in a non-null lexical environment. ... bindings needed by FOO by DEFUNs and DEFVAR / DEFPARAMETER so that FOO ...
    (comp.lang.lisp)
  • Re: Theories on why Lisp source *seems* to have less comments?
    ... "(FOO A B) returns the sum of A and B" ... The only problem is that the standard allows implementations to always ... FUNCTION-LAMBDA-EXPRESSION must be a function itself. ... ECL 0.9i ...
    (comp.lang.lisp)
  • Re: tail recusion fallacy?
    ... Common Lisp has dynamic variables and many implementations ... provide tail recursion optimization. ... Is Oliver wrong or do dynamic ...
    (comp.lang.lisp)