bug#58513: describe-function should say that defconst variables are constant

bug#58513: describe-function should say that defconst variables are constant

[Stefan Kangas]

Severity: wishlist

Evaluate this:

   (prog1 (defconst foo "bar" "help") (describe-variable 'foo))

How about adding a note to the help page of variables declared with
defconst saying that they are constants, or something to that effect?

bug#58513: describe-function should say that defconst variables are constant

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> Evaluate this:
>
>    (prog1 (defconst foo "bar" "help") (describe-variable 'foo))
>
> How about adding a note to the help page of variables declared with
> defconst saying that they are constants, or something to that effect?

I don't think we know that it's supposed to be constant?  Or do we,
somehow?  I thought it was just syntactic sugar, saying what our
intentions for the variable is.

But it doesn't really...  do anything, so we'd have to start to keep
track of which variables are really "constants".  Which would then be
confusing, because you can change values to these as with any other
variable.

bug#58513: describe-function should say that defconst variables are constant

[Phil Sainty]

On 2022-10-15 01:23, Lars Ingebrigtsen wrote:
> I thought it was just syntactic sugar, saying what our intentions
> for the variable is.

Yes, I think "not intended to be modified" is the gist.

Whether or not modifications would actually cause problems is unknown.

> But it doesn't really...  do anything

It does at least one thing different: if you load or eval a defconst
for a variable which already exists, the value is updated.

bug#58513: describe-function should say that defconst variables are constant

[Lars Ingebrigtsen]

Phil Sainty <psainty@orcon.net.nz> writes:

> It does at least one thing different: if you load or eval a defconst
> for a variable which already exists, the value is updated.

Yes, that's true.

And we could start adding a symbol property saying that a constant is
meant to be constant, and perhaps start warning if people change it, but
that would make things slower for basic things like `setq', so I'm
pretty sure it's not worth it.

We could use that property to make describe-function say that the
variable isn't meant to be changed, though.  But is it worth adding to
the symbol plist just for that?  Hm...

bug#58513: describe-function should say that defconst variables are constant

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> And we could start adding a symbol property saying that a constant is
> meant to be constant, and perhaps start warning if people change it, but
> that would make things slower for basic things like `setq', so I'm
> pretty sure it's not worth it.

Yes, incurring a run-time cost doesn't sound worth it, but we could
perhaps make the byte-compiler warn about it.

bug#58513: describe-function should say that defconst variables are constant

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> Yes, incurring a run-time cost doesn't sound worth it, but we could
> perhaps make the byte-compiler warn about it.

Yes, that's true...

I'm bringing Stefan M into this thread; perhaps he has some opinions.

bug#58513: describe-function should say that defconst variables are constant

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> Yes, incurring a run-time cost doesn't sound worth it, but we could
>> perhaps make the byte-compiler warn about it.

The byte-compiler already does warn about it, but only if the assignment
is in the same file as the `defconst`.

FWIW, my own local Emacs has `defconst` create actually
constant variables by adding a `SYMBOL_DEFCONST` to `enum
symbol_trapped_write`.  Admittedly I didn't make them really constant:
I allow a subsequent `defconst` to change the value set by a previous
`defconst`, but `setq` signals an error just like it does if you try to
`setq` on `enable-multibyte-characters` or on `nil`.

I didn't bother exporting this info to `describe-variable` (and the
byte-compiler) but it would be easy to do.


        Stefan

bug#58513: describe-function should say that defconst variables are constant

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> FWIW, my own local Emacs has `defconst` create actually
> constant variables by adding a `SYMBOL_DEFCONST` to `enum
> symbol_trapped_write`.  Admittedly I didn't make them really constant:
> I allow a subsequent `defconst` to change the value set by a previous
> `defconst`, but `setq` signals an error just like it does if you try to
> `setq` on `enable-multibyte-characters` or on `nil`.

Hm...  do you know if there's a performance impact from doing this?

bug#58513: describe-function should say that defconst variables are constant

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen [2022-10-14 16:25:30] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> FWIW, my own local Emacs has `defconst` create actually
>> constant variables by adding a `SYMBOL_DEFCONST` to `enum
>> symbol_trapped_write`.  Admittedly I didn't make them really constant:
>> I allow a subsequent `defconst` to change the value set by a previous
>> `defconst`, but `setq` signals an error just like it does if you try to
>> `setq` on `enable-multibyte-characters` or on `nil`.
>
> Hm...  do you know if there's a performance impact from doing this?

In terms of memory use, we already use 2 bits for that `enum
symbol_trapped_write`, so adding a new value doesn't cost anything
at all.

In terms of run-time, it adds a 4th branch to a few 3-branch `switch`
statements, so it can have a performance impact, most importantly in
`set_internal`, I guess, but I'd be very surprised if it's ever not lost
in the noise:

- it only affects `setq` on global/dynamic vars which should be a small
  fraction of the overall `setq` we perform nowadays.
- since that new branch always signals an error (well, in my own code,
  that is: I don't know what that branch would end up doing on `master`
  where we'd want to be more careful about backward compatibility), it's
  expected to be more-or-less never taken and even the most naive branch
  predictors should handle it "perfectly".


        Stefan

bug#58513: describe-function should say that defconst variables are constant

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> - since that new branch always signals an error (well, in my own code,
>   that is: I don't know what that branch would end up doing on `master`
>   where we'd want to be more careful about backward compatibility), it's
>   expected to be more-or-less never taken and even the most naive branch
>   predictors should handle it "perfectly".

I see; that sounds good.

So perhaps we should be moving in this direction, then.

That is, start by making defconst mark the variables (perhaps in the way
you've already implemented?), and then make byte-compilation warn about
assigning to defconsts (and make describe-function expose the
information, as requested).

And then, in a later Emacs version, we could start enforcing the
constness in running code.

bug#58513: describe-function should say that defconst variables are constant

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > And then, in a later Emacs version, we could start enforcing the
  > constness in running code.

defconst has had a subtle meaning: "It is ok to expect, in certain
limited ways, that the value will not be altered."  Nothing more.

This change may seem to be fixing a bug, but some old programs used to
take advantage of the actual old meaning.  This change might break
them.

I think that would be asking for trouble, and we have better things to
do than deal with that trouble.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#58513: describe-function should say that defconst variables are constant

[Drew Adams]

>   > And then, in a later Emacs version, we could start enforcing the
>   > constness in running code.
> 
> defconst has had a subtle meaning: "It is ok to expect, in certain
> limited ways, that the value will not be altered."  Nothing more.
> 
> This change may seem to be fixing a bug, but some old programs used to
> take advantage of the actual old meaning.  This change might break
> them.
> 
> I think that would be asking for trouble, and we have better things to
> do than deal with that trouble.

+1.
_____


FWIW, Common Lisp has `defconstant':

"Constant symbols defined by defconstant also become reserved
 and may not be further assigned to or bound (although they
 may be redefined, if necessary, by using defconstant again)."

https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node58.html#SECTION00912000000000000000

"...assert that the value of the variable name is fixed and
 does license the compiler to build assumptions about the
 value into programs being compiled. (However, if the compiler
 chooses to replace references to the name of the constant by
 the value of the constant in code to be compiled, perhaps in
 order to allow further optimization, the compiler must take
 care that such ``copies'' appear to be eql to the object that
 is the actual value of the constant. For example, the compiler
 may freely make copies of numbers but must exercise care when
 the value is a list.)"

https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node67.html#SECTION00932000000000000000

bug#58513: describe-function should say that defconst variables are constant

[Stefan Kangas]

Richard Stallman <rms@gnu.org> writes:

> defconst has had a subtle meaning: "It is ok to expect, in certain
> limited ways, that the value will not be altered."  Nothing more.

To my mind, the meaning is not subtle.  On the contrary, it is both
clear and well-documented.

The manual (info "(elisp) Defining Variables") explains:

    [defconst] defines SYMBOL as a value and initializes it.  It informs
    a person reading your code that SYMBOL has a standard global value,
    established here, that should not be changed by the user or by other
    programs.

From where I'm standing, this means that there is no practical
difference between a defconst and a defvar that Lisp code can rely on.

So, to give a somewhat contrived example, you can still break any
mathematical calculation in Emacs with:

    (setq float-pi 9)

The only way to not have your code break in the face of that is to
copy-paste the literal 3.141592... everywhere.

bug#58513: describe-function should say that defconst variables are constant

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> So, to give a somewhat contrived example, you can still break any
> mathematical calculation in Emacs with:
>
>     (setq float-pi 9)
>
> The only way to not have your code break in the face of that is to
> copy-paste the literal 3.141592... everywhere.

Yeah, but you can make the same argument for functions.  We allow
redefining `+' (and there's no warnings or nothing), but people don't
guard against that, either.

That said, we (in effect) have markup stating the intention for
`float-pi' to be a constant, so adding warnings when people redefine it
makes sense (because it's more likely that somebody does that as a
mistake instead of mistakenly redefining `+').

bug#58513: describe-function should say that defconst variables are constant

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> The byte-compiler already does warn about it, but only if the assignment
> is in the same file as the `defconst`.

I don't get any warnings with this recipe:

    echo "(defconst foo-bar t) (setq foo-bar nil)" > /tmp/foo.el
    emacs -Q -batch -eval '(byte-compile-file "/tmp/foo.el")'

Am I missing something?

bug#58513: describe-function should say that defconst variables are constant

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stefan Kangas [2022-10-15 12:33:29] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> The byte-compiler already does warn about it, but only if the assignment
>> is in the same file as the `defconst`.
> I don't get any warnings with this recipe:
>
>     echo "(defconst foo-bar t) (setq foo-bar nil)" > /tmp/foo.el
>     emacs -Q -batch -eval '(byte-compile-file "/tmp/foo.el")'
>
> Am I missing something?

Hmm... I don't get a warning either.  And looking at `bytecomp.el` I see
that we push stuff to `byte-compile-const-variables` but we never look
stuff up in it :-(

I'm pretty sure I wrote some code to use that variable (apparently
around 2003), but apparently it got lost in subsequent changes, probably
when we introduced lexical-binding.


        Stefan