Subject: bug#40671: [DOC] modify literal objects

From: Dmitry Gutov <[email-masked]>
Date: Tue, 28 Apr 2020 06:05:22 +0300

On 27.04.2020 04:49, Paul Eggert wrote:

>> Sorry, I don't have an Emacs 26 at hand. Should 25 suffice?
> 
> Yes.
> 
> Just tried this in
>> IELM:
>>
>> ELISP> (setq a '(1 . 2))
>> (1 . 2)
>>
>> ELISP> (setcdr a 3)
>> 3 (#o3, #x3, ?\C-c)
>> ELISP> a
>> (1 . 3)
> 
> Yes, the behavior is undefined in Emacs 25 too. Undefined means that the
> behavior you describe is allowed - in this instance you modified the "constant"
> and got away with it.

I'm not sure which problematic cases you mean, then. Ones related to 
pure space?

>> In Ruby, we also have "constants" and we sometimes laugh about being able to
>> change them. And yet, there also you can't do it by accident.
> 
> I suppose it depends on what one means by "accident". :-) Perhaps we could agree
> that accidents, whatever they are, happen more often in C....

It feels like you're just side-stepping the arguments, one after another.

>> We better warn against modifying any values that are part of a "literal object"
>> anywhere.
> 
> That's what the emacs-27 doc does, or at least tries to do.

I wish it did that without inventing new meanings for the words 
"constant" and "mutable". It will only breed confusion.

Take this paragraph:

     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.