[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#40671: [DOC] modify literal objects
From: |
Dmitry Gutov |
Subject: |
bug#40671: [DOC] modify literal objects |
Date: |
Tue, 28 Apr 2020 06:05:22 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 |
On 27.04.2020 04:49, Paul Eggert wrote:
Sorry, I don't have an Emacs 26 at hand. Should 25 suffice?
Yes.
Just tried this in
IELM:
ELISP> (setq a '(1 . 2))
(1 . 2)
ELISP> (setcdr a 3)
3 (#o3, #x3, ?\C-c)
ELISP> a
(1 . 3)
Yes, the behavior is undefined in Emacs 25 too. Undefined means that the
behavior you describe is allowed - in this instance you modified the "constant"
and got away with it.
I'm not sure which problematic cases you mean, then. Ones related to
pure space?
In Ruby, we also have "constants" and we sometimes laugh about being able to
change them. And yet, there also you can't do it by accident.
I suppose it depends on what one means by "accident". :-) Perhaps we could agree
that accidents, whatever they are, happen more often in C....
It feels like you're just side-stepping the arguments, one after another.
We better warn against modifying any values that are part of a "literal object"
anywhere.
That's what the emacs-27 doc does, or at least tries to do.
I wish it did that without inventing new meanings for the words
"constant" and "mutable". It will only breed confusion.
Take this paragraph:
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.
- bug#40671: [DOC] modify literal objects, (continued)
- bug#40671: [DOC] modify literal objects, Paul Eggert, 2020/04/26
- bug#40671: [DOC] modify literal objects, Philipp Stephani, 2020/04/26
- bug#40671: [DOC] modify literal objects, Paul Eggert, 2020/04/26
- bug#40671: [DOC] modify literal objects, Dmitry Gutov, 2020/04/26
- bug#40671: [DOC] modify literal objects, Paul Eggert, 2020/04/26
- bug#40671: [DOC] modify literal objects, Dmitry Gutov, 2020/04/26
- bug#40671: [DOC] modify literal objects, Paul Eggert, 2020/04/26
- bug#40671: [DOC] modify literal objects,
Dmitry Gutov <=
- bug#40671: [DOC] modify literal objects, Paul Eggert, 2020/04/28
- bug#40671: [DOC] modify literal objects, Dmitry Gutov, 2020/04/28
- bug#40671: [DOC] modify literal objects, Paul Eggert, 2020/04/28
- bug#40671: [DOC] modify literal objects, Dmitry Gutov, 2020/04/28
- bug#40671: [DOC] modify literal objects, Paul Eggert, 2020/04/28
- bug#40671: [DOC] modify literal objects, Dmitry Gutov, 2020/04/28
- bug#40671: [DOC] modify literal objects, Paul Eggert, 2020/04/28
- bug#40671: [DOC] modify literal objects, Dmitry Gutov, 2020/04/28
- bug#40671: [DOC] modify literal objects, Paul Eggert, 2020/04/28
- bug#40671: [DOC] modify literal objects, Dmitry Gutov, 2020/04/28