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

Previous Next

Full log

Message #222 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 01:17:46 -0700

On 4/27/20 8:05 PM, Dmitry Gutov wrote:

> I'm not sure which problematic cases you mean, then. Ones related to pure space?

That's one issue. Earlier versions of Emacs also had trouble if you modified
list structures while executing them. I've squashed some of those issues more
recently but would not be surprised if some remain.

I don't know how much optimization the byte compiler did in earlier versions,
but if it did anything like what it does now, that's also a source of problems.

>     Although all numbers are constants and all markers are
>   mutable, some types contain both constant and mutable members.  These
>   types include conses, vectors, strings, and symbols.  For example, the
>   string
>   literal @code{"aaa"} yields a constant string, whereas the function
>   call @code{(make-string 3 ?a)} yields a mutable string that can be
>   changed via later calls to @code{aset}.
> 
> It makes one think that 'aset' can't be called on "aaa". That it will either
> fail to change the value, or signal an error. Whereas the result is that the
> value is changed, no errors or warnings.

'aset' *shouldn't* be called on "aaa".

We could replace "a constant string" with "a constant string that should not be
changed"; would that help?

> It feels like you're just side-stepping the arguments, one after another. 

There's certainly no intent to side-step. And I don't sense that there's really
much disagreement here: we both agree that the current behavior is unfortunate,
the major point of disagreement is about terminology in the documentation.

Previous Next

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