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

Previous Next

Full log

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: Mattias Engdegård <mattiase <at> acm.org>,
 Eli Zaretskii <eliz <at> gnu.org>, 40671 <at> debbugs.gnu.org, ke.vigouroux <at> laposte.net
Subject: Re: bug#40671: [DOC] modify literal objects
Date: Sun, 19 Apr 2020 15:41:09 -0700

On 4/19/20 2:57 PM, Michael Heerdegen wrote:

> I had a quick look at your changes.  I agree that it would have been
> better to discuss before you start to install what you think you like.

Yes, in hindsight I suppose you're right. If you like I can revert the changes now.

> Before your changes the manual used the
> term "literal" objects, now you added a different wording "constant"
> vs. "mutable" that describes more or less the same thing.

Thanks, I hadn't recalled that use of "literal object" (in the Equality 
Predicates) section. Although the two notions are related they're not identical. 
For example, the reason one shouldn't modify byte-code objects is not the 
sharing issue mentioned in Equality Predicates: it's because doing so can make 
Emacs crash.

That being said, it would be helpful discuss the two notions in a unified way 
rather than separately, as is the case now.

> Then some things you added are just wrong, at least in the generality
> you word them.  As Drew said, `quote' doesn't always return constant
> objects, the special form just returns the OBJECT, whatever it is, when
> it is evaluated.

It depends on what one means by "constant" objects. If we uniformly changed that 
word to "literal" would that remove the objection? For example, although 
byte-code objects aren't normally what one would think of as being "literal", we 
could simply define them to be "literal".

> |  Vectors written with square brackets are constants and should not be
> |  modified via @code{aset} or other destructive operations.
> 
> (let ((l (list 1 2 3)))
>    (let ((my-vector `[,@l]))
>      my-vector))
> 
> What does this sentence tell me about the vector I constructed?

Nothing, just as the documentation for splicing also says nothing about that 
vector. These are both deficiencies in the documentation that should get fixed 
(and in some form the deficiencies both predate the recent changes).

Previous Next

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