bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#40671: [DOC] modify literal objects


From: Paul Eggert
Subject: bug#40671: [DOC] modify literal objects
Date: Tue, 28 Apr 2020 01:17:46 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]