bug#40671: [DOC] modify literal objects

[Dmitry Gutov]

On 02.05.2020 09:28, Paul Eggert wrote:
> 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.

"glass objects" or "voldemort objects" all sound better to me. :-)

"unchanging" is one of the meanings of "constant". It's a property of a 
process, not something we can call a value out of context.

CLtL uses the term "coalesced", though. We can consider it.

> > 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.

An unchanging string is just a string that nobody changed. "Please don't 
change unchanging strings" is a prohibition of time travel.

> 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.

The "objects that appear as a constant" are objects to which exist 
references from executable code, and where such references are 
"constant" (or possibly constant, since an implementation might opt not 
to coalesce the values). That why it's about constant references (and 
objects to which such references exist).

> > 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.

Not just because of that.

> > 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.

Examples?

I mean,

  A mutable object can become constant if it is part of an expression
  that is evaluated

does add some cases not covered by self-evaluating forms, but those are 
more complex cases (e.g. creating forms programmatically and then 
passing them to 'eval'), and then the programmer might justifiably be 
expected to use their head. The self-evaluating forms case is arguably 
less obvious.