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

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

> 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.

That's indeed a risk, but it's one that's a lot easier to manage.

> In contrast, llet would prevent conflict in that case.

Right, you can introduce llet and llet* and then some more l<foos> for
macros that expand to uses of `let' or `let*' and ....

Or you can take a page from Common-Lisp's book and run with it.

I chose the second option.  It's not perfect, but so far I don't regret it.

> (Global) specialness ambushes code that uses Lisp's standard «let», because
> «let» lets outside code decide how to bind the symbols.

That's true, which is why I added the annoying warnings to `defvar' when
the symbol seems not to use a prefix.

> And it happens to be faster.

It should make 0 difference to byte-compiled code and I don't care much
about the speed of the non-byte-compiled code.

> 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».

Again: no speed difference in byte-compiled code.

>> 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.

Using the same identifiers sometimes as a lexical var and sometimes as
a dynamic var is evil for the poor human reader.  Si I have no intention
to try and refine the semantics of such cases.


        Stefan