[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why is Elisp's defvar weird? And is eval_sub broken?
From: |
Stefan Monnier |
Subject: |
Re: Why is Elisp's defvar weird? And is eval_sub broken? |
Date: |
Mon, 16 Feb 2015 02:40:19 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) |
> 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
- Why is Elisp's defvar weird? And is eval_sub broken?, Kelly Dean, 2015/02/12
- Re: Why is Elisp's defvar weird? And is eval_sub broken?, Stefan Monnier, 2015/02/13
- Re: Why is Elisp's defvar weird? And is eval_sub broken?, Kelly Dean, 2015/02/14
- Re: Why is Elisp's defvar weird? And is eval_sub broken?, Stefan Monnier, 2015/02/14
- Re: Why is Elisp's defvar weird? And is eval_sub broken?, Daniel Colascione, 2015/02/15
- Re: Why is Elisp's defvar weird? And is eval_sub broken?, Kelly Dean, 2015/02/16
- Re: Why is Elisp's defvar weird? And is eval_sub broken?,
Stefan Monnier <=
- Re: Why is Elisp's defvar weird? And is eval_sub broken?, Kelly Dean, 2015/02/17
- Re: Why is Elisp's defvar weird? And is eval_sub broken?, Stefan Monnier, 2015/02/18
- Re: Why is Elisp's defvar weird? And is eval_sub broken?, Kelly Dean, 2015/02/19
- Re: Why is Elisp's defvar weird? And is eval_sub broken?, Stefan Monnier, 2015/02/19
- Re: Why is Elisp's defvar weird? And is eval_sub broken?, Kelly Dean, 2015/02/19
- Re: Why is Elisp's defvar weird? And is eval_sub broken?, Stefan Monnier, 2015/02/19
- Proposal for a closed-buffer tracker, Kelly Dean, 2015/02/21
- Re: Proposal for a closed-buffer tracker, Eli Zaretskii, 2015/02/22
- Re: Proposal for a closed-buffer tracker, Stefan Monnier, 2015/02/22
- Re: Proposal for a closed-buffer tracker, Dmitry Gutov, 2015/02/22