bug#40671: [DOC] modify literal objects

[Paul Eggert]

On 5/10/20 5:44 PM, Dmitry Gutov wrote:

> "Indeed"?

Indeed yes. :-)

> The changing "mutability" status is imaginary, however.

It's part of a spec. Not every constraint in a spec needs to be enforced
directly by the implementation. That doesn't mean these constraints are 
"imaginary".
> This also requires the reader to read the manual without missing a reference. 
> A
> regular person would not understand your meaning of "mutable" without 
> following
> the reference to {Mutability}.

If a paragraph says "mutable" and has a cross-reference to the "Mutability"
section, that's good enough. This is a reference manual, not a tutorial, and we
can assume a reasonable level of competence on the part of the reader.
> Does is ignore the possibility of the example in the previous version, then?

I don't understand this remark.

> I'm trying to point out the incompatibility with the regular meanings of the
> words used.

>> Because it's not an accurate statement of the problem. The set of objects 
>> that
>> might be shared differs from the set of objects that should not change. The
>> Mutability node focuses on the latter set of objects, and gives the former 
>> as an
>> example but it is not the only sort of object that should not change.
> 
> But if we don't mention such cases in "Mutability", where do we cover them?

Fair enough. I added an example of such a case to "Mutability" in the proposal
in my most-recent email (Bug#40671#441).
> +(let* ((x (list 0.5))
> +       (y (eval (list 'quote x))))
> +  (setcar x 1.5) ;; The program should not do this.
> +  y)
> 
> Why is this a problem? Do we expect this it could lead to a segfault?

Probably not a segfault in the current implementation, but the behavior isn't
defined. And we don't want the behavior to be defined, as that would prohibit
some optimizations that may be coming down the road.