bug#55914: 28.1; Defining as dynamic an already lexical var

bug#55914: 28.1; Defining as dynamic an already lexical var

[Hendrik Tews]

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

bug#55914: 28.1; Defining as dynamic an already lexical var

[Phil Sainty]

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.

bug#55914: 28.1; Defining as dynamic an already lexical var

[Phil Sainty]

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.

bug#55914: 28.1; Defining as dynamic an already lexical var

[Hendrik Tews]

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

bug#55914: 28.1; Defining as dynamic an already lexical var

[Lars Ingebrigtsen]

Hendrik Tews <hendrik.tews@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