bug#40671: [DOC] modify literal objects

[Paul Eggert <eggert@cs.ucla.edu>]

On 4/28/20 12:33 PM, Dmitry Gutov wrote:

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

The word "constant" means different things in different programming languages.
The meaning used in the Elisp manual is reasonably close to its meaning in
C/C++/Fortran/Common Lisp/etc., and that describes how Emacs behaves now. We'd
prefer it if Emacs behaved more like what Python does with its immutable
objects, and some day we should change Emacs to do that. When we do so, we can
modify the Elisp manual accordingly. In the meantime we need to document what we
have.

> Emacs users are not C programmers.

Of course not, but this area needs documentation and when the Emacs concept is
similar to an already-existing one in C/C++/etc. it's not necessarily a bad
thing to adopt their terminology and/or notation, even if that
terminology/notation happens to mean something else in other contexts.

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

Then I don't understand your suggestion.

I thought you were saying that we should distinguish among the types of
constants and should say what happens when you modify each type. The manual
already does this to a very limited extent, and I thought you were suggesting
that it should do a reasonably exhaustive job of it, in order to greatly limit
the area where Emacs behavior is undefined.

I'd rather not go that route generally, for the reasons stated above. That being
said, it might make sense to make some changes in this area. Or perhaps I'm
still misunderstanding you, in which case further clarification would be helpful.

A simple way to be clear in this area is to propose specific wording changes,
preferably in git format-patch form. It's not enough to say "I don't like the
word 'constant'."

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

Yes, and the documentation does that now. The edge of the wild is the line
between constants and non-constants. A program that tries to modify a constant
is out in the wilderness.