GNU bug report logs - #40671
[DOC] modify literal objects

Previous Next

Full log

View this message in rfc822 format

From: Drew Adams <drew.adams <at> oracle.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, Mattias Engdegård <mattiase <at> acm.org>, 40671 <at> debbugs.gnu.org, Richard Stallman <rms <at> gnu.org>, ke.vigouroux <at> laposte.net
Subject: bug#40671: [DOC] modify literal objects
Date: Fri, 1 May 2020 15:05:11 -0700 (PDT)

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.