bug#40671: [DOC] modify literal objects

[Dmitry Gutov]

On 28.04.2020 22:20, Paul Eggert wrote:
> On 4/28/20 11:46 AM, Dmitry Gutov wrote:
>
> > That sounds like something we have to fix.
>
> Yes, absolutely, though we can't feasibly do that before the next release.

Yeah, ok.

> > That's not a constant, that's an eldritch abomination.
>
> I say "constant", you say "eldritch". :-)

And then I explain why "constant" is bad, multiple times. With examples 
from other languages.

> > Using semantics that might be "slightly familiar"
> > only to grizzled C programmers is also bad.
>
> It's not just "slightly familiar" to grizzled C/C++/etc. programmers. It's a
> concept that's pretty much part of their daily lives.

You take the concept of "constant values", look it up in the C standard 
(where modifying a constant is "undefined behavior") and then make a 
conclusion that if modifying something is "undefined behavior", it must 
be called a constant. Outside of C standard, to boot.

Emacs users are not C programmers.

> > There is a particular kind of values called fizzleworp (see {String literals}, 
> > {Quote} and {Backquote}), which are dangerous to modify.
>
> Let's not go that route. It'd be overdocumenting internal details that are not
> generally known. I don't know all the details, so I couldn't write all that
> documentation without a lot of nontrivial investigation. And these details are
> likely to change so users should not rely on them anyway.

That's not what I was suggesting. I gave an example on using the words, 
not on which cases to enumerate.

> Instead of going out into the wilderness and tagging and identifying each dragon
> and its lair, the documentation should keep things simple and merely say "there
> are dragons out in the wilderness; you shouldn't go there". This is much simpler
> and easier to understand and maintain, and is safer overall.

The map still has to circle the wilderness on the map somehow.

> > Lisp form literals, and any members of such forms. I might be forgetting 
> > something, but this list is not too long, is it?
>
> Yes the list isn't *that* long, and it's in the documentation already - as long
> as we are willing to put up with a conservative list (e.g., you shouldn't modify
> anything in the list) rather than insisting on an exhaustive list (e.g., here's
> what happens if you try to modify X, here's what happens if you try to modify Y,
> etc.).

Conservative list is fine, as long as we don't use the word "constant".