Re: emacs-27 eebfb72 1/2: Document constant vs mutable objects better

[Paul Eggert]

On 4/19/20 3:33 PM, Štěpán Němec wrote:

> Regarding comparing two equal floats, strings or lists by `eq', you warn
> about its undefinedness ("might not return nil") repeatedly, but can you
> give an actual example where (eq 1.2 1.2) or (eq "string" "string")
> returns non-nil in Elisp?

  (let ((str "abc"))
    (eq str "abc"))

This yields t when byte-compiled.

> I still think that formulations like
> "the other arguments (all but the last) should be mutable lists" are
> unfortunate, because all Elisp lists are mutable.

Pure lists are not mutable. (Admittedly these are getting rare...)

> All lists/strings/vectors are
> mutable in Elisp.

No, there are exceptions. For example the following makes my Emacs dump core, 
even though all it does is modify a string.

  (aset (symbol-name 'cons) 0 ?x)

It's trying to change the spelling of the name of the 'cons' function, but that 
spelling is in memory that the operating system protects on my platform.

> I don't think calling the
> same data structure once "mutable" and once not will help rather than
> confuse or mystify.

Yes, we should definitely be consistent in whatever terminology we use. And it's 
quite plausible that the terminology in the current (emacs-27) manual can be 
improved. However, I don't know what terminology people would prefer. ("Literal 
object" is one possibility, but it has its own problems.)


> > +  A self-evaluating form yields a constant, and you should not attempt
> > +to modify the constant's contents via @code{setcar}, @code{aset} or
> > +similar primitives.  The Lisp interpreter might unify the constants
>             ^^^^^^^^^^
> In the Elisp manual, "primitive" is defined as "A function which is
> callable from Lisp but is actually written in C", but I think we want to
> say that one shouldn't try to modify constants, period; no matter the
> particular means used.

Thanks, I changed "primitives" to "operations".