bug#40671: [DOC] modify literal objects

[Paul Eggert]

On 5/1/20 6:07 PM, Dmitry Gutov wrote:

> They very rarely use the phrase "constant objects", however. Instead, it's
> almost always "objects that appears as a constant [in code]", "object ... used
> as a quoted constant", "object may not ... appear as constants in code",
> "objects are similar as a constant".

We could use similar circumlocutions. Or instead of saying "constant" we could
say "unchanging", as distinct from "unchangeable". (It beats
"object-that-should-not-be-changed" or "glass object - you changed it, you broke
it!". :-) The usual word for this notion is "constant", though.

> IOW, it's the difference between constant values and constant pointers to
> [mutable] values.

I don't see that. A constant (or "unchanging") string is like a mutable string,
except you shouldn't change it. There's no sense in CLtL in which a mutable
object must be implemented via a pointer to a value whereas a constant must not
be implemented that way.
> there is no juxtaposition of "mutable objects" vs "constant objects"
> anywhere in there

Yes, the mutable/immutable terminology revolution happened mostly after CLtL was
written.

> So the section
> "Constants and Mutability", even though it has valuable information, could 
> use a
> full rewrite. And could probably move to end of the "Self-Evaluating Forms"
> section.

Whether an object is constant is distinct from whether it's derived from a
self-evaluating form, because one can have constants that were never derived
from any self-evaluating form. Any doc rewrite should be careful to keep the two
notions distinct, quite plausibily (though not necessarily) in different 
sections.

> I can try to make a patch, but at this point is would consist mostly of 
> deletions.

Certainly some stuff could be deleted (the tutorial could be trimmed as you
suggest, for example), but we should keep the baby while we're throwing out the
bathwater. And if we're using circumlocutions the text is likely to get longer,
not shorter.