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

[Štěpán Němec]

On Wed, 22 Apr 2020 10:54:12 -0700
Paul Eggert wrote:

> 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.

Thanks.

>> 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.

I meant the list examples you changed: you would never actually use

 (memq (list 2) '((1) (2)))

instead of (memq '(2) '((1) (2))), same as you'd never use
`copy-sequence' to make sure you have a fresh comparison key.

Rather, the point of that section is to use `member' instead of `memq',
analogously to `assoc' vs `assq' above.

>> 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.

I still think we are miscommunicating due to the different usage or
notion of "mutable". All I'm saying is that if you introduce wording
such as "the other arguments (all but the last) should be mutable
lists", that (to me, and I'm sure many other readers) implies that you
are talking about (types of) data structures, i.e. that there is such a
thing as mutable (and also immutable, because why would you use that
term otherwise?) lists/conses/strings as opposed to something else, as
there indeed is in some languages, including Scheme (e.g. SRFI 140) or
Racket.

I'm not saying that the difference between the values of (symbol-name
'lambda), "lambda" and (copy-sequence "lambda") or (list 1) vs '(1)
aren't real, important or worth clarifying, only that unqualified
"mutable" is an unfortunate term to use (and AFAICT you introduce this
usage to the documentation; it was pretty much nonexistent before your
recent changes).

-- 
Štěpán