unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#58513: describe-function should say that defconst variables are constant
@ 2022-10-14 12:04 Stefan Kangas
  2022-10-14 12:23 ` Lars Ingebrigtsen
  0 siblings, 1 reply; 16+ messages in thread
From: Stefan Kangas @ 2022-10-14 12:04 UTC (permalink / raw)
  To: 58513

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?





^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#58513: describe-function should say that defconst variables are constant
  2022-10-14 12:04 bug#58513: describe-function should say that defconst variables are constant Stefan Kangas
@ 2022-10-14 12:23 ` Lars Ingebrigtsen
  2022-10-14 12:35   ` Phil Sainty
  0 siblings, 1 reply; 16+ messages in thread
From: Lars Ingebrigtsen @ 2022-10-14 12:23 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: 58513

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.





^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#58513: describe-function should say that defconst variables are constant
  2022-10-14 12:23 ` Lars Ingebrigtsen
@ 2022-10-14 12:35   ` Phil Sainty
  2022-10-14 12:40     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 16+ messages in thread
From: Phil Sainty @ 2022-10-14 12:35 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Stefan Kangas, 58513

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.







^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#58513: describe-function should say that defconst variables are constant
  2022-10-14 12:35   ` Phil Sainty
@ 2022-10-14 12:40     ` Lars Ingebrigtsen
  2022-10-14 13:03       ` Stefan Kangas
  0 siblings, 1 reply; 16+ messages in thread
From: Lars Ingebrigtsen @ 2022-10-14 12:40 UTC (permalink / raw)
  To: Phil Sainty; +Cc: Stefan Kangas, 58513

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...





^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#58513: describe-function should say that defconst variables are constant
  2022-10-14 12:40     ` Lars Ingebrigtsen
@ 2022-10-14 13:03       ` Stefan Kangas
  2022-10-14 13:07         ` Lars Ingebrigtsen
  0 siblings, 1 reply; 16+ messages in thread
From: Stefan Kangas @ 2022-10-14 13:03 UTC (permalink / raw)
  To: Lars Ingebrigtsen, Phil Sainty; +Cc: 58513

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.





^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#58513: describe-function should say that defconst variables are constant
  2022-10-14 13:03       ` Stefan Kangas
@ 2022-10-14 13:07         ` Lars Ingebrigtsen
  2022-10-14 13:34           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 16+ messages in thread
From: Lars Ingebrigtsen @ 2022-10-14 13:07 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: Phil Sainty, Stefan Monnier, 58513

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.





^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#58513: describe-function should say that defconst variables are constant
  2022-10-14 13:07         ` Lars Ingebrigtsen
@ 2022-10-14 13:34           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-10-14 14:25             ` Lars Ingebrigtsen
  2022-10-15 12:33             ` Stefan Kangas
  0 siblings, 2 replies; 16+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-14 13:34 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Phil Sainty, Stefan Kangas, 58513

>> 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






^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#58513: describe-function should say that defconst variables are constant
  2022-10-14 13:34           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-14 14:25             ` Lars Ingebrigtsen
  2022-10-14 16:44               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-10-15 12:33             ` Stefan Kangas
  1 sibling, 1 reply; 16+ messages in thread
From: Lars Ingebrigtsen @ 2022-10-14 14:25 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Phil Sainty, Stefan Kangas, 58513

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?





^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#58513: describe-function should say that defconst variables are constant
  2022-10-14 14:25             ` Lars Ingebrigtsen
@ 2022-10-14 16:44               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-10-15 10:04                 ` Lars Ingebrigtsen
  0 siblings, 1 reply; 16+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-14 16:44 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Phil Sainty, Stefan Kangas, 58513

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






^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#58513: describe-function should say that defconst variables are constant
  2022-10-14 16:44               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-15 10:04                 ` Lars Ingebrigtsen
  2022-10-16 20:51                   ` Richard Stallman
  0 siblings, 1 reply; 16+ messages in thread
From: Lars Ingebrigtsen @ 2022-10-15 10:04 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Phil Sainty, Stefan Kangas, 58513

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.





^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#58513: describe-function should say that defconst variables are constant
  2022-10-14 13:34           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-10-14 14:25             ` Lars Ingebrigtsen
@ 2022-10-15 12:33             ` Stefan Kangas
  2022-10-15 14:11               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  1 sibling, 1 reply; 16+ messages in thread
From: Stefan Kangas @ 2022-10-15 12:33 UTC (permalink / raw)
  To: Stefan Monnier, Lars Ingebrigtsen; +Cc: Phil Sainty, 58513

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?





^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#58513: describe-function should say that defconst variables are constant
  2022-10-15 12:33             ` Stefan Kangas
@ 2022-10-15 14:11               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 0 replies; 16+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-15 14:11 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: Phil Sainty, Lars Ingebrigtsen, 58513

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






^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#58513: describe-function should say that defconst variables are constant
  2022-10-15 10:04                 ` Lars Ingebrigtsen
@ 2022-10-16 20:51                   ` Richard Stallman
  2022-10-16 21:11                     ` Drew Adams
  2022-10-17  5:41                     ` Stefan Kangas
  0 siblings, 2 replies; 16+ messages in thread
From: Richard Stallman @ 2022-10-16 20:51 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: psainty, stefan, monnier, 58513

[[[ 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)







^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#58513: describe-function should say that defconst variables are constant
  2022-10-16 20:51                   ` Richard Stallman
@ 2022-10-16 21:11                     ` Drew Adams
  2022-10-17  5:41                     ` Stefan Kangas
  1 sibling, 0 replies; 16+ messages in thread
From: Drew Adams @ 2022-10-16 21:11 UTC (permalink / raw)
  To: rms@gnu.org, Lars Ingebrigtsen
  Cc: psainty@orcon.net.nz, stefan@marxist.se, monnier@iro.umontreal.ca,
	58513@debbugs.gnu.org

>   > 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


^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#58513: describe-function should say that defconst variables are constant
  2022-10-16 20:51                   ` Richard Stallman
  2022-10-16 21:11                     ` Drew Adams
@ 2022-10-17  5:41                     ` Stefan Kangas
  2022-10-17 10:41                       ` Lars Ingebrigtsen
  1 sibling, 1 reply; 16+ messages in thread
From: Stefan Kangas @ 2022-10-17  5:41 UTC (permalink / raw)
  To: rms, Lars Ingebrigtsen; +Cc: psainty, monnier, 58513

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.





^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#58513: describe-function should say that defconst variables are constant
  2022-10-17  5:41                     ` Stefan Kangas
@ 2022-10-17 10:41                       ` Lars Ingebrigtsen
  0 siblings, 0 replies; 16+ messages in thread
From: Lars Ingebrigtsen @ 2022-10-17 10:41 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: psainty, 58513, rms, monnier

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 `+').





^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2022-10-17 10:41 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-10-14 12:04 bug#58513: describe-function should say that defconst variables are constant Stefan Kangas
2022-10-14 12:23 ` Lars Ingebrigtsen
2022-10-14 12:35   ` Phil Sainty
2022-10-14 12:40     ` Lars Ingebrigtsen
2022-10-14 13:03       ` Stefan Kangas
2022-10-14 13:07         ` Lars Ingebrigtsen
2022-10-14 13:34           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-14 14:25             ` Lars Ingebrigtsen
2022-10-14 16:44               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-15 10:04                 ` Lars Ingebrigtsen
2022-10-16 20:51                   ` Richard Stallman
2022-10-16 21:11                     ` Drew Adams
2022-10-17  5:41                     ` Stefan Kangas
2022-10-17 10:41                       ` Lars Ingebrigtsen
2022-10-15 12:33             ` Stefan Kangas
2022-10-15 14:11               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).