bug#40671: [DOC] modify literal objects

[Drew Adams <drew.adams@oracle.com>]

> Symbols are constant AFAICT, their bindings
> are not (variables are not constant).

Their bindings as variables are not constant, except
for keyword symbols, nil, and t (are there any others?).

But are symbols otherwise constant, besides their
values?  Depends what you mean by "symbol", perhaps.
Certainly you can change not only `symbol-value' but
also `symbol-function' and `symbol-plist'.  I don't
see symbols as very constant.

[Personally, as I suggested, I don't think the text
about this gotcha should get down in the weeds about
mutable/immutable anything.  I think it should stay
general, not try to catalog specific problems (e.g.
strings, conses, whatever).

It should show and explain a very simple example of
what can happen with a quoted list, and then leave
it at that.  Maybe it should mention, as you said a
while back, that there are the reader, interpreter,
and byte compiler, when saying something about the
problem in general.  But I already said all this,
and I said I was done here...]

BTW, in Common Lisp you can even do nasty things
like modify the `symbol-name' of a symbol.  For that,
CLTL2 says: 

"It is an extremely bad idea to modify a string
 being used as the print name of a symbol. Such
 a modification may tremendously confuse the
 function `read' and the package system."

That's the _kind_ of somewhat vague gotcha
description I think we should have.  Enough to
let users know they don't want to do it.

> > +  A mutable object stops being mutable if it is part of an
> expression
> > +that is evaluated.  For example:
> 
> FWIW, I would feel better about the word "mutable" if you would
> introduce the term like "safely mutable", and then say that we call it
> just "mutable" in the following sections because this is shorter.  Drew
> mentioned his dislike for the term "safe" AFAIR 

I don't recall saying that, but I may have.  Not
sure what's meant here.  I objected to using
"dangerous", as if the gotcha was generally
hazardous to life.

> but I think "my Emacs
> won't crash if I follow this" vs. "it can crash" describes some kind of
> safety.  Ignore if this comment is irrelevant because this is already
> done or treated otherwise.

To me, the problem for users is not so much that
Emacs can crash as it is that they may lose data.

Or more likely (and worth mentioning, I think, as
a motivator) that they might have a heck of a time
trying to figure out why their code doesn't seem
to behave as they expect.  Seeing a quoted list
in source code can make you think new list
structure is created each time that code is run.

Code "initializing" part of some list structure
to a quoted list might give you the impression
that that's what happens each time (e.g. each
time a function that seems to do that gets called),
but the same cons from a first evaluation (or
reading) of that quoted list might remain in use
for each invocation of the function.  And if you
at some point modify that cons then you might not
get your apparent "initialization" to that quoted
list each time the function's invoked.

> > +  When the same value appears multiple times
                     ^^^^^ ^^^^^^^
> > +in a program, the Lisp interpreter might save
> > +time or space by reusing existing values or
                                       ^^^^^^
> > +their components.
> 
> I think we call "values" what evaluation of expressions yields, so
> values don't appear in a program (to be read).  I don't know the
> backgrounds and when this can happen.  Is it always the interpreter
> that does this mapping?

I think that text wasn't too bad, but I see your point.

And it's especially not good to use "value" in the two
different senses, as (1) something you see ("appears")
in a source program and (2) a runtime value that results
from reading, byte-compiling, or interpreting that source
code.

Maybe "object" or "Lisp object" instead of "value", for
#2?

(Note: I didn't read the full text.  I'm just reacting
to what was cited in your mail.  Sorry.)