Re: lexical-binding questions

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> Also, it reminded my of this:
>> (setq lexical-binding t)
>> (let ((t 0)) t)      => error
>> (let ((nil 0)) nil)  => 0

Funnily enough, the byte-compiler behaves pretty much the same, and yet
the underlying reasons are completely different.

Basically: nil and t are not marked as special-variable-p, so they are
considered candidates for lexical scoping; but t is used as the last
element of the interpreter's lexical environment (basically because
a nil lexical environment is used to mean "lexical-binding = nil"), so
it behaves as if there'd been a (defvar t) earlier, which in turns
explains why the error is signalled since we then try to set the global
variable `t' which is immutable.

For nil, this doesn't show up, so it's treated as a lexically
scoped var.

for the compiler case, byte-compile-not-lexical-var-p actually
special-cases t and nil so they're treated as dynamically bound, but in
your nil case above, we never even attempt to bind nil because the "let body
is nil" triggers an optimization (which (c|sh)ould also apply to the
"let body is t" case, but that's not implemented).

Anyway, I guess nil and t should be marked as special-variable-p, if for
no other reason than because they are pretty damn special.


        Stefan