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: Tue, 28 Apr 2020 17:55:22 -0700 (PDT)

> I don't see why we should depart from terminology used by 
> C/C++/Fortran/Common Lisp/etc.; it's reasonably well-established.

You're _not_ using the language that's used for Common Lisp.

I echoed what the CL doc said.  Elisp corresponds
to the behavior of CLTL1 in this regard, not to any
later update that makes the interpreter behave more
like compiled code (raising an error in both).

Like CLTL1, we should just warn about the gotcha,
not say that it's about modification or attempted
modification of "constants".

A few mails ago, you wondered if the disagreement
has been only about terminology.  And the response
was mostly "Yes" - objections to your use of
"mutable" and "constant"/"immutable", and your use
of "cannot" instead of "should not" (aka "Don't").

You've since ignored that response, it seems.  This
has dragged on, just circling.  I, for one, give up.

But I do hope you'll listen to others.  And yes,
Michael's point about committing before discussing
& deciding is spot on too.  Remember your curly-quote
crusade?  You did the same thing then, with similar
complaints about acting widely, unilaterally, and
prematurely.

My suggestion is to see how people have already
warned users about this gotcha here & there (forums
etc.) and do likewise.  Come to an agreement about
the behavior to warn users about - in practical,
operational, but not exhaustive, terms.

A simple quoted-list example is enough, along with
a general description.  Once there's agreement
about the message, including any example(s), the
wording will fall out naturally.  (At least the
wording won't be a battleground, once the message
is decided on.)

Previous Next

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