emacs-devel
[Top][All Lists]
Advanced

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

Re: emacs-27 eebfb72 1/2: Document constant vs mutable objects better, R


From: Paul Eggert
Subject: Re: emacs-27 eebfb72 1/2: Document constant vs mutable objects better, Re: emacs-27 eebfb72 1/2: Document constant vs mutable objects better, Re: emacs-27 eebfb72 1/2: Document constant vs mutable objects better
Date: Wed, 22 Apr 2020 10:54:12 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

On 4/20/20 3:05 AM, Štěpán Němec wrote:

how about, rather than giving examples that you would
never use in real code, we change the examples as follows:

           (assq "simple leaves" leaves)
                ⇒ unspecified ; might be nil or non-nil
           (assoc "simple leaves" leaves)
                ⇒ ("simple leaves" . oak)

Yes, that's fine. I installed the attached patch, which attempts to address this, along with other comments by you and Drew.

Similarly for the others.

What similar examples are there? As far as I can tell, the other newly-introduced uses of copy-sequence are needed for mutability not uniqueness, so they aren't similar.

the examples you give IMO
don't illustrate that some strings or lists are mutable and some are
not; it illustrates that mutating some lists or strings has undefined
consequences.

I have a different impression, I think the string that (symbol-name 'lambda) returns really is constant. Currently Emacs doesn't behave well if you try to change that string (and Emacs should behave better): but it's a feature not a bug that you can't mess up the Lisp interpreter in such a fundamental way, and if we make improvements in this area they should not change the fact that these string values should stay constant.

The point I have been trying to make is that, especially now that
immutable (/persistent/functional) data structures are quite widespread,
using the mutable/immutable dichotomy in the way you do for Elisp is
confusing

But the Elisp documentation doesn't contrast "mutable" with "immutable"; it contrasts "mutable" with "constant". The documentation avoids the word "immutable" partly to try to avoid the confusion that you mention.

There are other languages where "constant" or "const" means "behavior is undefined if you try to change it", not "an exception is thrown if you try to change it"; C and C++ are notable examples. So it's not like the documentation is inventing terminology out of whole cloth here.

If one's expectation is that Emacs will throw an exception if one tries to modify a constant then that's unfortunate, because Emacs doesn't do that for all constants. For now, the manual documents what you can do safely in a Elisp code; if we improve Emacs so that it reliably signals an error when you try to modify any constant then we can change the manual to say so.

Attachment: 0001-Improve-wording-about-constants.patch
Description: Text Data


reply via email to

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