bug#40671: [DOC] modify literal objects

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

On 4/19/20 10:32 PM, Drew Adams wrote:

> Giving it an existing name (e.g. "constant"), which means
> something else

In informal language the word "constant" can mean different things to different 
people. If the manual defines the word "constant" to mean "an object whose value 
should never change" and it uses that word consistently, then that's OK; the 
manual's terminology corresponds closely enough to the informal one. Of course 
if we can come up with a better phrase than "constant" then we should use that; 
but so far we haven't seemed to be able to.

> Explain the gotcha in one place, and if
> need to refer to that explanation elsewhere then do so
> (link).

Yes, that's what's done now.

> If Emacs can crash or remove your home directory,
> that's a bug, IMO.  We don't document bugs

We should advise Lisp programmers about what they can do safely, and what they 
should not do due to Emacs's unfortunate limitations. We already do this in 
other dangerous areas (e.g., what happens if you increase max-lisp-eval-depth 
too far), and we should do it in this dangerous area too. You're right that we 
needn't document in detail what happens if a Lisp program does unsafe things.

> we certainly shouldn't let Emacs crash

If we can fix the problem that would be better, yes. However, it's not practical 
to do that for Emacs 27 because it is so close to release and any fix would 
require major surgery. It's not clear that it's practical to fix things even for 
Emacs 28.

> Saying some behavior
> is undefined is never (in my experience) done knowing
> it crashes the program.

Welcome to the wonderful world of undefined behavior. I'm joking of course; 
undefined behavior is not a good thing. But here we are.

> Maybe say that just reading the '(1 2 3) creates a
> list, and that thereafter that same list is used by
> the byte compiler.

Thanks, I'll add something along those lines.