bug#40671: [DOC] modify literal objects

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

>> There's no sense in CLtL in which a mutable
>> object must be implemented via a pointer to a value whereas a constant must not
>> be implemented that way.
> 
> The "objects that appear as a constant" are objects to which exist references
> from executable code, and where such references are "constant" (or possibly
> constant, since an implementation might opt not to coalesce the values). That
> why it's about constant references (and objects to which such references exist).

I don't understand this point.

It sounds like you might be trying to distinguish between constant references
(i.e., pointers that don't change) and constant objects implemented via
references (i.e., the pointed-to values don't change). However, whether the
references themselves are constant is independent of the issue at hand. The
issue wouldn't change, for example, if Emacs relocated objects so that
references were updated regardless of whether the objects' values were constant.

>> Whether an object is constant is distinct from whether it's derived from a
>> self-evaluating form, because one can have constants that were never derived
>> from any self-evaluating form.
> 
> Examples?

One example is (aset (symbol-name 'car) 0 ?d), which I mentioned a while ago.
Here's a trickier one:

(let ((constant-string (aref (symbol-function 'error) 1)))
  (aset constant-string 0 183)
  (number-sequence 0 1 0))

This also provokes undefined behavior at the C level while number-sequence is
doing its thing; my Emacs dumps core, yours may do something different. I'm sure
there are other examples. The point is that programs should not modify constants.

It would be nice if Emacs reliably signaled these errors and we should be able
to do a better job of that than we're doing now. However, doing a better job
would require interpreter surgery that would be too much for emacs-27.

>   A mutable object can become constant if it is part of an expression
>   that is evaluated
> 
> does add some cases not covered by self-evaluating forms, but those are more
> complex cases (e.g. creating forms programmatically and then passing them to
> 'eval'), and then the programmer might justifiably be expected to use their
> head. The self-evaluating forms case is arguably less obvious.

The documentation should not limit itself to self-evaluating forms when
discussing this problem area. Although it's OK for the doc to emphasize
self-evaluating forms, they are not the whole story here.