bug#40671: [DOC] modify literal objects

[Dmitry Gutov]

On 11.05.2020 04:57, Paul Eggert wrote:
> On 5/10/20 5:44 PM, Dmitry Gutov wrote:
>
> > "Indeed"?
>
> Indeed yes. :-)

That paragraph doesn't scan. You could replace that word with "And", though.

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

Part of the "spec" you just added in this series of patches.

I think that's exactly what a "constraint" means: something that is 
enforced.

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

Curious case of an meaningful reference where I have to construct the 
URL manually anyway. The symbol-name example? I'm not sure it's really 
important to warn about this one in particular.

But are we effectively saying "there exist values that are unsafe to 
modify, for example, any return values of symbol-name", and that's it? 
When one tries to describe "unsafe" things to do, they don't just give a 
few examples, they usually try to cover all cases. Perhaps by including 
some false positives (which the 'let*' example below, I think, is), but 
trying hard to avoid false negatives.

Inventing a name for such values doesn't help if the user doesn't have 
enough knowledge to avoid all members of this set. Or is "part of an 
expression that is evaluated" after all the test we'll be teaching?

By the way, I have read last two paragraphs of that section now. C and 
"constants" are still there.

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

I'm curious to see the discussion about actually making this error at 
runtime in one of the next Emacs version.