bug#40671: [DOC] modify literal objects

[Michael Heerdegen <michael_heerdegen@web.de>]

Paul Eggert <eggert@cs.ucla.edu> writes:

> I'm attaching two patches.

Thanks for the continued work on this, I appreciate the improvements and
the general direction.  I may have missed parts of the discussion
recently, sorry if some comments are unsubstantial.

So, a few questions about the patches:

> +  Although numbers never change and all markers are mutable,
> +some types have members some of which are mutable and others not.  These
> +types include conses, vectors, strings, and symbols.  For example,
> +although @code{"aaa"} yields a string that should not be changed,
> +@code{(make-string 3 ?a)} yields a mutable string that can be
>  changed via later calls to @code{aset}.

Is this a good statement?  The string read syntax, and the syntax for
lists makes it easy to make such objects part of a program.  But all
classes of objects you call mutable can end up as part of a program.
Are there any classes of "types" where all members are always mutable?

Second point: you mix up objects vs. object evaluation.  For conses you
speak about the objects, for symbols about the binding (i.e. the result
of the evaluation).  Conses can also be evaluated (most programs are
conses), but that's surely not what you want to describe.  I would not
say symbols are mutable.  Symbols are constant AFAICT, their bindings
are not (variables are not constant).

> +  A mutable object stops being mutable if it is part of an expression
> +that is evaluated.  For example:

FWIW, I would feel better about the word "mutable" if you would
introduce the term like "safely mutable", and then say that we call it
just "mutable" in the following sections because this is shorter.  Drew
mentioned his dislike for the term "safe" AFAIR but I think "my Emacs
won't crash if I follow this" vs. "it can crash" describes some kind of
safety.  Ignore if this comment is irrelevant because this is already
done or treated otherwise.

> +  When the same value appears multiple times in a program, the Lisp
> +interpreter might save time or space by reusing existing values or
> +their components.  For example, @code{(eq "abc" "abc")} returns

I think we call "values" what evaluation of expressions yields, so
values don't appear in a program (to be read).  I don't know the
backgrounds and when this can happen.  Is it always the interpreter that
does this mapping?

"Same syntax" is not good as well:

   (eq (list 1 2 3) (list 1 2 3))

doesn't provoke the pitfall you warn about, but your wording doesn't
make clear why the one case is ok and the other is not.  Maybe it's
again as simple as saying something about objects as being part of a
program?


Thanks again,

Michael.