bug#40671: [DOC] modify literal objects

[Drew Adams <drew.adams@oracle.com>]

> >> Here's a quote from CLtL2 (page 115):
> >>
> >> "it is an error to destructively modify any object that appears as a
> >> constant in executable code, whether within a 'quote' special form or as
> >> a self-evaluating form."
> >
> > As Drew pointed out (and if I understood this correctly), the above
> > specification leads to implementations that do raise an error when
> > someone tried to modify such a value.
> 
> Although those implementations conform to the Common Lisp spec, that's
> because the spec explicitly says such behavior is undefined - which means
> implementations can signal an error, dump core, or do whatever else
> they want.
> See
> <https://urldefense.com/v3/__https://www.cs.cmu.edu/Groups/AI/html/cltl
> /clm/node11.html__;!!GqivPVa7Brio!NeqWMrCFKgi8Ktwdz5aIkeBh_-TPzH-
> XiJbWDMeSRu1VKiI70b5LK6Sy2v5CMxaq$ >, which uses
> "should" in the same sense the emacs-27 elisp manual uses "should".

I stand corrected.  I was assuming that the "proposal"
I cited had actually been adopted for CLTL2.

So CLTL2 is in the same boat as CLTL(1), in the regard
relevant to this thread: There is NO systematic raising
of an error - no prevention of the gotcha.

So what I said about Elisp being like CLTL(1) applies
also to CLTL2:  We should NOT say that you _cannot_
do XYZ (because you might be able to, and the behavior
if you try is undefined).  We should instead say that
you _should not_.

We're still circling, though.  But thanks for clarifying
that "it's an error" meaning.  I misremembered that as
meaning that a conformant implementation is required to
raise an error.  I was thinking/assuming that the cited
proposal was in fact adopted as part of the CL definition.