emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lexical-binding is turned on in more use cases


From: Stefan Monnier
Subject: Re: lexical-binding is turned on in more use cases
Date: Mon, 09 Mar 2020 18:05:12 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

> Why is (defvar foo) a no-op?

Because that's what it has been since its introduction many many years
ago (Emacs-21? 20? 19? 18?).

In Emacs-24, a decision had to made about how to deal with it.
Given the many packages that did (and many still do) things like

   (defvar date)

making such defvars have global impacts means that any code using `date`
as a lexical variable would break whenever that other package with the
`(defvar date)` happened to be loaded.

This is still true if that other package does

    (defvar date nil)

but such definition of variables with no namespace prefix has been
widely understood as a bug since "for ever", so they're vanishingly rare
(contrary to the (defvar <VAR>) where <VAR> doesn't have a namespace
prefix, which I also consider as bugs but are still very widespread).

So the Emacs-24 design of lexical-binding make (defvar <VAR>) be
a declaration which only affects "the current scope".

I don't claim it is a perfect design, but it's what we have (introduced
in Emacs-24) and in retrospect it has worked fairly well, striking
a pretty good balance between the desire to minimize the amount of
changes needed when converting a file from dynamic to lexical scoping,
the need to work alongside the many pre-existing files which won't be
changed, the need to provide reasonably sane semantics which aren't too
badly affected by "unrelated" packages, ...

> Why does it not set the declared_special bit inside the symbol?

As explained, this would make lots of existing packages break other
unrelated packages.  In any case, this boat has sailed many years ago.

>> It's rather unusual.
> Even if that's the case, it doesn't make it unimportant.  Let binding
> from the minibuffer should work consistently, its effect not varying
> chaotically between dynamic and lexical binding.

let-binding is the thing that is different between dynamic and lexical
binding, so it is affected, by definition.  As for "chaotically", it's
a matter of judgment.  You're clearly not familiar with the behavior
of lexical-binding, so it's no surprise you find it chaotic.

> See above.  defvar should not be a no-op.

It was designed as a no-op from the very beginning, long before
`lexical-binding` was introduced.  `lexical-binding` is what made it less
of a no-op, so it seems you're arguing on favor of
`lexical-binding` unwittingly.

> It shouldn't be necessary to write (defvar foo) in more than one file.

Then write (defvar foo nil).

> Why did you not initiate a discussion on emacs-devel before committing
> this patch?

It was discussed somewhere for a while.  Lesseee....  Oh, I found it:

    https://debbugs.gnu.org/30078


-- Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]