bug#40671: [DOC] modify literal objects

[Dmitry Gutov]

On 10.05.2020 20:29, Paul Eggert wrote:
> On 5/9/20 8:13 PM, Dmitry Gutov wrote:
>
> > You start talking about objects that "should [not] change". And give an example
> > of an object that _cannot_ change.
>
> That's easily altered to also give an example of an object that should not
> change; see attached patch.

Quoting the new paragraph. Now it goes "should not" -> "cannot":

+  Some Lisp objects should never change.  For example, the Lisp
+expression @code{"aaa"} yields a string, but you should not change
+its contents.  Indeed, some objects cannot be changed; for example,
+although you can create a new number by calculating one, Lisp provides
+no operation to change the value of an existing number.

"Indeed"?

> > I could understand it if it was describing an existing type system of the
> > language, or implementation internals, but this is a purely imaginary type
> > system.
>
> objects.texi already talks about the Emacs Lisp type system and specifically
> mentions strings, conses, etc. as types. Even if one considers the Emacs Lisp
> type system to be "imaginary", it's reasonable to use the documentation's
> already-existing terminology here.

Strings, conses, etc, are anything but imaginary (try using one in a 
function that expects another, and you'll almost always get a runtime 
error). The changing "mutability" status is imaginary, however.

This also requires the reader to read the manual without missing a 
reference. A regular person would not understand your meaning of 
"mutable" without following the reference to {Mutability}. Which not 
everybody is going to do, and which is harder to do when reading a 
printed version.

> > the list object didn't change, just an outside reference to its head was
> > created,
>
> The attached patch alters the example so that the list object does change (or at
> least tries to).

Does is ignore the possibility of the example in the previous version, then?

> > The opposite of "mutable" is "immutable". Are string literals immutable? They 
> > are
> > not.
>
> They might be mutable, and they might not be. The documentation deliberately
> doesn't say, because we don't want to document the details (they have changed in
> the past and are likely to change in the future).

I'm trying to point out the incompatibility with the regular meanings of 
the words used.

Also see Michael's suggestion.

> > Overall the phrase "that might be shared" is a good replacement. Why not keep to
> > it?
>
> 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?

I'm also looking at the new example:

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

Evaluating this expression in IELM leads to a stable result. Putting it 
in a function doesn't bring any surprises either.

Example:

ELISP> (defun test (v)
(let* ((x (list v))
       (y (eval (list 'quote x))))
  (setcar x 1.5)
  y))
test
ELISP> (test 3)
(1.5)

It's an advanced, yes, but clearly the expected behavior if someone 
wrote a function like that.