bug#40671: [DOC] modify literal objects

[Dmitry Gutov <dgutov@yandex.ru>]

On 28.04.2020 11:17, Paul Eggert wrote:
> On 4/27/20 8:05 PM, Dmitry Gutov wrote:
> 
>> I'm not sure which problematic cases you mean, then. Ones related to pure space?
> 
> That's one issue. Earlier versions of Emacs also had trouble if you modified
> list structures while executing them. I've squashed some of those issues more
> recently but would not be surprised if some remain.

If any led to segfaults, they have to be fixed in the code anyway.

> I don't know how much optimization the byte compiler did in earlier versions,
> but if it did anything like what it does now, that's also a source of problems.

Well, here's a damning example. And it doesn't involve the byte compiler:

ELISP> (defun abc () "abc")
abc
ELISP> (aset (abc) 0 ?b)
98 (#o142, #x62, ?b)
ELISP> (abc)
"bbc"

I wonder how other Lisps deal with that.

The Ruby interpreter, from the first release I think, always created 
copies of the literals when a method was called. Exactly to avoid this 
kind of broken semantics.

In the recent versions, they added a pragma string (to be added to the 
top of the file) that makes all such literals in that file "immutable". 
That means that any attempt to change them errors at runtime. And now 
it's considered good style to use that pragma everywhere.

>>      Although all numbers are constants and all markers are
>>    mutable, some types contain both constant and mutable members.  These
>>    types include conses, vectors, strings, and symbols.  For example, the
>>    string
>>    literal @code{"aaa"} yields a constant string, whereas the function
>>    call @code{(make-string 3 ?a)} yields a mutable string that can be
>>    changed via later calls to @code{aset}.
>>
>> It makes one think that 'aset' can't be called on "aaa". That it will either
>> fail to change the value, or signal an error. Whereas the result is that the
>> value is changed, no errors or warnings.
> 
> 'aset' *shouldn't* be called on "aaa".

Indeed it shouldn't.

> We could replace "a constant string" with "a constant string that should not be
> changed"; would that help?

That sounds like a weird tautological non-advice.

It shouldn't be changed because it's a value of a string literal. Not 
because it's constant (it isn't).

>> It feels like you're just side-stepping the arguments, one after another.
> 
> There's certainly no intent to side-step. And I don't sense that there's really
> much disagreement here: we both agree that the current behavior is unfortunate,
> the major point of disagreement is about terminology in the documentation.

 From the outset all arguments were about the terminology.