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

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: 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: bug#40671: [DOC] modify literal objects
Date: Tue, 28 Apr 2020 22:33:50 +0300

On 28.04.2020 22:20, Paul Eggert wrote:
> 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.

Yeah, ok.

>> That's not a constant, that's an eldritch abomination.
> 
> I say "constant", you say "eldritch". :-)

And then I explain why "constant" is bad, multiple times. With examples 
from other languages.

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

You take the concept of "constant values", look it up in the C standard 
(where modifying a constant is "undefined behavior") and then make a 
conclusion that if modifying something is "undefined behavior", it must 
be called a constant. Outside of C standard, to boot.

Emacs users are not C programmers.

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

That's not what I was suggesting. I gave an example on using the words, 
not on which cases to enumerate.

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

The map still has to circle the wilderness on the map somehow.

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

Conservative list is fine, as long as we don't use the word "constant".

Previous Next

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