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

Previous Next

Full log

Message #327 received at 40671 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>, Paul Eggert <eggert <at> cs.ucla.edu>
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: RE: bug#40671: [DOC] modify literal objects
Date: Thu, 30 Apr 2020 22:15:53 -0700 (PDT)

> >> You're _not_  using the language that's used for Common Lisp.
> > In what sense does the language differ? 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.

That's my understanding.  I believe that wasn't
the case for CLTL(1) - there was no such promise
or requirement.  And I think it's also not the
case for Elisp.  Like CLTL(1), we should just
warn users about the gotcha, since there's no
protection from it.

To be clear, I'm no expert on CLTL2.  I used
CL for years before that.  The gotcha bit me
once, having modified the result of a quoted
list - and then someone explained what was
happening.

It's too easy for a newbie to think only in
terms of textual source code being interpreted.
It's easy not to realize, as Michael said, that
there's the Lisp reader, the interpreter, and
the byte-compiler, and each might get a chance
to handle a quoted list.  And just how they did
so was not specified.

Presumably, a conformant CL implementation now
protects you from this gotcha.

Previous Next

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