bug#40671: [DOC] modify literal objects

[Dmitry Gutov]

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.