GNU bug report logs - #55914
28.1; Defining as dynamic an already lexical var

Previous Next

To reply to this bug, email your comments to 55914 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Hendrik Tews <hendrik.tews <at> kernkonzept.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.1; Defining as dynamic an already lexical var
Date: Sat, 11 Jun 2022 23:33:24 +0200

Hi,

evaluating

    (let ((test-var nil))
      (eval '(defvar test-var t "XXX")))

works fine in emacs 27 but fails in 28.1 with "Defining as
dynamic an already lexical var", similarly for defcustom instead
of defvar.

The elisp manual 28.1 says in 12.5 Defining Global Variables:

     If SYMBOL is already lexically bound (e.g., if the ‘defvar’ form
     occurs in a ‘let’ form with lexical binding enabled), then ‘defvar’
     sets the dynamic value.

From this I would conclude that the error is a bug. Or did I
overlook something in the documentation?

(I noticed this problem because of failing tests for Proof
General with emacs 28, see
https://github.com/ProofGeneral/PG/issues/657. There, inside a
let binding a Coq file is opened, which causes the Coq instance
of Proof General to be loaded, which somewhere contained a
defcustom for the variable that was bound with let.)

Best regards,

Hendrik Tews

Message #8 received at 55914 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Hendrik Tews <hendrik.tews <at> kernkonzept.com>
Cc: 55914 <at> debbugs.gnu.org
Subject: Re: bug#55914: 28.1; Defining as dynamic an already lexical var
Date: Sun, 12 Jun 2022 12:10:04 +1200

On 2022-06-12 09:33, Hendrik Tews wrote:
> From this I would conclude that the error is a bug. Or did I
> overlook something in the documentation?

It sounds like it's been upgraded from a mere description to an
error, and the point would be "definitely don't do that; and if
you see this then you should treat it as a bug to be fixed".


> (I noticed this problem because of failing tests for Proof
> General with emacs 28, see
> https://github.com/ProofGeneral/PG/issues/657. There, inside a
> let binding a Coq file is opened, which causes the Coq instance
> of Proof General to be loaded, which somewhere contained a
> defcustom for the variable that was bound with let.)

Which indicates a bug to be fixed, no?

If the variable is *supposed* to be dynamic (everywhere), then
lexical libraries which refer to it must declare (defvar FOO) to
mark it as a dynamic variable, if it's possible that the proper
definition may not yet have been loaded.

If the variable is supposed to be lexical, then it should be
renamed to something which doesn't clash with a dynamic variable.
There's need for hyphenated name-spacing for lexical vars, so the
majority of single-word names are particularly safe to use.

Message #11 received at 55914 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Hendrik Tews <hendrik.tews <at> kernkonzept.com>
Cc: 55914 <at> debbugs.gnu.org
Subject: Re: bug#55914: 28.1; Defining as dynamic an already lexical var
Date: Sun, 12 Jun 2022 14:10:42 +1200

On 2022-06-12 12:10, Phil Sainty wrote:
> There's need for hyphenated name-spacing for lexical vars, so the
> majority of single-word names are particularly safe to use.

That should have been:

There's *no* need for hyphenated name-spacing for lexical vars.

Message #14 received at 55914 <at> debbugs.gnu.org (full text, mbox):

From: Hendrik Tews <hendrik.tews <at> kernkonzept.com>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: 55914 <at> debbugs.gnu.org
Subject: Re: bug#55914: 28.1; Defining as dynamic an already lexical var
Date: Sun, 12 Jun 2022 10:54:52 +0200

Hi,

thanks for your quick answer.

> Which indicates a bug to be fixed, no?

Well, not as long as the documentation clear states that in this
case the dynamic value is set.

> If the variable is *supposed* to be dynamic (everywhere), then
> lexical libraries which refer to it must declare (defvar FOO) to
> mark it as a dynamic variable, if it's possible that the proper
> definition may not yet have been loaded.

Is this statement in the manual somewhere? If not, would you mind
adding it?

Best regards,

Hendrik Tews

Message #17 received at 55914 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Hendrik Tews <hendrik.tews <at> kernkonzept.com>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 55914 <at> debbugs.gnu.org
Subject: Re: bug#55914: 28.1; Defining as dynamic an already lexical var
Date: Sun, 12 Jun 2022 12:33:59 +0200

Hendrik Tews <hendrik.tews <at> kernkonzept.com> writes:

> The elisp manual 28.1 says in 12.5 Defining Global Variables:
>
>      If SYMBOL is already lexically bound (e.g., if the ‘defvar’ form
>      occurs in a ‘let’ form with lexical binding enabled), then ‘defvar’
>      sets the dynamic value.
>
>>From this I would conclude that the error is a bug. Or did I
> overlook something in the documentation?

There's been some back and forth about what happens in these cases.
This section in the manual currently reads (in Emacs 29):

---
If @var{symbol} is already let bound (e.g., if the @code{defvar}
form occurs in a @code{let} form), then @code{defvar} sets the toplevel
default value, like @code{set-default-toplevel-value}.
---

However, your test case signals an error, so I think the documentation
needs further clarifications here:

    (let ((test-var nil))
      (eval '(defvar test-var t "XXX")))

I've added Stefan to the CCs.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.