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

[Paul Eggert]

On 5/2/20 5:50 AM, Štěpán Němec wrote:

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

I see your point. That's easy enough to fix; I installed the attached patch.

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

That's OK. It's not a misimpression to think of things that way. True, Scheme
SRFI 140 has a lot more detail, with functions like istring? that Elisp lacks,
but the core idea is close enough and it would be nice if Elisp eventually grew
in the same direction as Scheme in this area (though obviously this would be a
much bigger project than merely fiddling with the documentation).

I just checked, and Scheme has gone in the Elisp direction recently in this
area: although R6RS took the strong position that safety is essential, R7RS says
it's not - e.g., R7RS like R5RS says that (car 0) can cause the interpreter to
crash (though of course interpreters are suggested to behave more nicely than
that). This change to the Scheme spec was for performance reasons that Elisp is
not immune to.

0001-Make-memq-etc.-examples-more-like-they-were.patch
Description: Text Data