Re: Is add-to-list supposed to work when lexical-binding is t?

[Kelly Dean]

Stefan Monnier wrote:
>> I don't see cases where quote-var would fail to do what's intended.
>We can have gv-ref/quote-var/quote-lex/younameit, but what we can't do
>is merge it with quote, because their semantics are incompatible:
>        (eq (let ((x 1)) (quote-var x)) (let ((x 1)) (quote-var x)))
>should return nil, whereas
>        (eq (let ((x 1)) (quote x)) (let ((x 1)) (quote x)))
>should return t.

True, and that's a good way to explain the difference between a variable and a 
symbol. On June 5 I wrote, "If overloading quote is a bad idea, then quote-lex 
should return a reference to the current instance of the given variable 
regardless of whether it's given a lexical or global variable", which means
(defvar x 1)
(eq (quote-var x) (quote-var x))
should return t. But
(eq (gv-ref x) (gv-ref x))
returns nil, so gv-ref isn't a suitable substitute for quote-var.

I further wrote, "that means in the latter case, it does the same thing as 
quote", which means I was confusing variables with symbols. :-)

And further, "which means quote-lex can be used instead of quote in all places, 
except where a symbol needs to be returned despite that symbol also serving as 
a lexical variable in the same scope, because the symbol will be used as the 
global variable or as something other than a variable."
Which now I think should be: in order to avoid a type error, quote-var _must_ 
be used, unless the symbol will be used as something other than a variable. But 
then there are a couple problems: 1, Lisp can't detect the type error anyway, 
so what's the point? And 2, if you actually do need to quote a global variable 
that's shadowed by a lexical variable, there's no way to do it except (quote 
global-var), yet that's a type error. I suppose the answer to the second 
problem is: don't shadow the global; use a different name for the lexical.

To solve the first problem, I think set and symbol-value would have to signal 
an error if given a non-variable symbol, and eq would have to distinguish 
variables and symbols:
(setq x 1)
(symbol-value (quote-var x)) -> 1
(symbol-value (quote x)) -> type error
(eq (quote x) (quote-var x)) -> type error
which also means symbol-value would more appropriately be called 
"variable-value", which seems reasonable anyway, since non-variable (well, and 
non-constant) symbols don't have values.
But it's just an academic argument, since signalling such errors would break 
everything.

In my previous message I wrote:
>For completeness, either (setq indent-line-function 'my-indent-func) should 
>signal a type error, or "'x" should be read as (quote-var x), and (setq 
>cursor-type 'bar) should signal a type error

But the type error can't be detected until indent-line-function or cursor-type 
is used. Oops.
This concludes my public conversation with myself for today.

Your example above explains symbol vs. variable. To explain variable vs. 
instance:
(defun foo (&optional p_x)
  (let ((x))
    (if p_x (eq p_x (quote-var x))
      (foo (quote-var x)))))
(foo) -> nil
which also means maybe "quote-var" isn't a good name either; "younameit" might 
be just as good!

Barry Margolin wrote:
>> When eval sees the symbol x, and is going to interpret it as a lexical 
>> variable, as it does in your example, it looks up, in the current lexical 
>> environment
>Since eval is just an ordinary function, it doesn't have access to the 
>lexical environment.

The elisp manual, section 11.9.3 Lexical Binding, says:
"When the Lisp evaluator wants the
current value of a variable, it looks first in the lexical environment;
if the variable is not specified in there, it looks in the symbol's
value cell, where the dynamic value is stored."

Did I miss something?