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

Previous Next

Full log

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 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: Re: bug#40671: [DOC] modify literal objects
Date: Tue, 28 Apr 2020 12:20:21 -0700

On 4/28/20 11:46 AM, Dmitry Gutov wrote:

> That sounds like something we have to fix.

Yes, absolutely, though we can't feasibly do that before the next release.

> That's not a constant, that's an eldritch abomination.

I say "constant", you say "eldritch". :-)

> Using semantics that might be "slightly familiar"
> only to grizzled C programmers is also bad.

It's not just "slightly familiar" to grizzled C/C++/etc. programmers. It's a
concept that's pretty much part of their daily lives.

> There is a particular kind of values called fizzleworp (see {String literals}, {Quote} and {Backquote}), which are dangerous to modify.

Let's not go that route. It'd be overdocumenting internal details that are not
generally known. I don't know all the details, so I couldn't write all that
documentation without a lot of nontrivial investigation. And these details are
likely to change so users should not rely on them anyway.

Instead of going out into the wilderness and tagging and identifying each dragon
and its lair, the documentation should keep things simple and merely say "there
are dragons out in the wilderness; you shouldn't go there". This is much simpler
and easier to understand and maintain, and is safer overall.

> Lisp form literals, and any members of such forms. I might be forgetting something, but this list is not too long, is it? 

Yes the list isn't *that* long, and it's in the documentation already - as long
as we are willing to put up with a conservative list (e.g., you shouldn't modify
anything in the list) rather than insisting on an exhaustive list (e.g., here's
what happens if you try to modify X, here's what happens if you try to modify Y,
etc.).

Previous Next

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