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

[Kelly Dean <kelly@prtime.org>]

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.