bug#40671: [DOC] modify literal objects

[Dmitry Gutov <dgutov@yandex.ru>]

On 28.04.2020 20:59, Paul Eggert wrote:
> On 4/28/20 6:54 AM, Dmitry Gutov wrote:
>> It shouldn't be changed because it's a value of a string literal. Not because
>> it's constant (it isn't).
> 
> That depends on the string literal and the particular Emacs implementation. In
> Emacs master, some string literals yield strings that are constant because Emacs
> has undefined behavior at the C level (maybe coredump, maybe not)

That sounds like something we have to fix. Emacs shouldn't dump core no 
matter what Lisp code the user wrote. Unless it leads to an OOM, I guess.

> if you try to
> change them, some string literals are constant because if you try to change them
> Emacs will reliably signal an error, some string literals are constant because
> if you change them Emacs might behave unpredictably without having undefined
> behavior at the C level, and the remaining string literals are constant becase
> you shouldn't change them.

That's not a constant, that's an eldritch abomination. Some unknown, 
unpredictable thing. Which is generally bad for language semantics and 
for its users. I understand why it's hard to fix that, but co-opting 
common words to mean different things is bad. Using semantics that might 
be "slightly familiar" only to grizzled C programmers is also bad.

If you really want to have an adjective for such values, either ask some 
language theorist or make up one (and I'm only half-kidding here).

Example: Some values in Emacs are constant, meaning you can't change 
them (e.g. you can't change an integer), and some are mutable (e.g. a 
cons cell is easy to change). There is a particular kind of values 
called fizzleworp (see {String literals}, {Quote} and {Backquote}), 
which are dangerous to modify. Please take care not to do that in your code.

<... some enumeration of situation which create fizzleworp values or 
make an existing value fizzleworp ...>

OR

Anyplace we introduce literals in the manual, if they are dangerous to 
modify, we say that. Without inventing new words.

> We have never documented exactly which string
> literals are which, and we shouldn't document that now because it is an
> implementation detail that users should not rely upon.

No argument here.

> It would be a mistake for the documentation to say that the problems we've been
> discussing occur only with string literals, as these problems can occur for
> strings that were not generated from string literals, and they can also occur
> for objects that are not strings. So "string literal" would be the wrong
> terminology here.

String literals, Lisp form literals, and any members of such forms. I 
might be forgetting something, but this list is not too long, is it?