Re: Why is Elisp's defvar weird? And is eval_sub broken?

[Kelly Dean]

Stefan Monnier wrote:
>>> Normally, such conflicts should never happen
>>> because all special vars should be named with a "package prefix", but
>>> sadly, reality is different, so it was indispensable to make this
>>> effect local, to allow lexical-binding code to work reliably.
>> By using llet, the byte compiler will catch such conflicts, and your code
>> (interpreted or compiled) that uses it will work reliably despite the
>> conflicts. This means defvar's weird behavior is no longer needed.
>
> It's not weird once you understand that it's a compiler directive which
> is absent from the .elc file.

If Elisp's defvar with no init value is used, then it avoids conflict, but the 
packages that are a problem in the first place (by declaring 
non-package-prefixed symbols special) will also be ones that tend to use defvar 
_with_ an init value (so the symbols really are declared special, and their 
defvars are in the elc). Elisp's defvar doesn't prevent conflict in that case, 
so it seems the local-specialness feature doesn't fulfill its intended purpose.

In contrast, llet would prevent conflict in that case.

(Global) specialness ambushes code that uses Lisp's standard «let», because 
«let» lets outside code decide how to bind the symbols. Elisp's local 
specialness just lets the outside code decline to launch the ambush. In 
contrast, llet ensures that the ambush will fail. That's why it's the better 
solution. And it happens to be faster.

And dlet is a faster way of doing what you can currently do in Elisp using 
defvar (with no init value) followed by standard «let». Except dlet causes only 
local dynamicness (called functions can read/set the variables it binds), which 
is all it needs, not local specialness (makes following «let»s bind 
dynamically) like Elisp's defvar does.

>> A declaration of free dynamic variables for a function could tell the
>> byte compiler that those free variables aren't typos, since
>> otherwise the byte compiler would expect either the symbol to be
>> declared special or a lexical variable by that name to be in scope.
>
> There is such a declaration already.  It's called (defvar <foo>).  Tada!

Yes, though using defvar for this declaration in the function also causes local 
specialness, when all that's needed in this case is just to tell the byte 
compiler that the variables aren't mistakes.