From: Paul Eggert <eggert@cs.ucla.edu>
To: "Štěpán Němec" <stepnem@gmail.com>
Cc: Michael Heerdegen <michael_heerdegen@web.de>, emacs-devel@gnu.org
Subject: Re: emacs-27 eebfb72 1/2: Document constant vs mutable objects better
Date: Sat, 2 May 2020 14:08:21 -0700 [thread overview]
Message-ID: <8d7d73a2-e0c2-c43f-1125-534493752c91@cs.ucla.edu> (raw)
In-Reply-To: <871ro24i1p.fsf@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1770 bytes --]
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.
[-- Attachment #2: 0001-Make-memq-etc.-examples-more-like-they-were.patch --]
[-- Type: text/x-patch, Size: 2978 bytes --]
From 0a3731feef351f6af47bed1458aefb6cb481b5f9 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sat, 2 May 2020 13:48:21 -0700
Subject: [PATCH] Make memq etc. examples more like they were
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Problem reported by Štěpán Němec in:
https://lists.gnu.org/r/emacs-devel/2020-05/msg00130.html
* doc/lispref/lists.texi (Sets And Lists, Association Lists):
Revert examples to be more like the way they were, using
self-evaluating expressions. Be more consistent about listing
unspecified results.
---
doc/lispref/lists.texi | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/doc/lispref/lists.texi b/doc/lispref/lists.texi
index ea44e01f48..fcaf4386b1 100644
--- a/doc/lispref/lists.texi
+++ b/doc/lispref/lists.texi
@@ -1242,8 +1242,8 @@ compare @var{object} against the elements of the list. For example:
@result{} (b c b a)
@end group
@group
-(memq '(2) '((1) (2))) ; @r{@code{(2)} and @code{(2)} are not @code{eq}.}
- @result{} nil
+(memq '(2) '((1) (2))) ; @r{The two @code{(2)}s need not be @code{eq}.}
+ @result{} @r{Unspecified; might be @code{nil} or @code{((2))}.}
@end group
@end example
@end defun
@@ -1356,12 +1356,12 @@ Compare this with @code{memq}:
@example
@group
-(memql 1.2 '(1.1 1.2 1.3)) ; @r{@code{1.2} and @code{1.2} must be @code{eql}.}
+(memql 1.2 '(1.1 1.2 1.3)) ; @r{@code{1.2} and @code{1.2} are @code{eql}.}
@result{} (1.2 1.3)
@end group
@group
-(memq 1.2 '(1.1 1.2 1.3)) ; @r{@code{1.2} and @code{1.2} need not be @code{eq}.}
- @result{} nil ; @r{... or it might be @code{(1.2 1.3)}.}
+(memq 1.2 '(1.1 1.2 1.3)) ; @r{The two @code{1.2}s need not be @code{eq}.}
+ @result{} @r{Unspecified; might be @code{nil} or @code{(1.2 1.3)}.}
@end group
@end example
@end defun
@@ -1380,12 +1380,12 @@ Compare this with @code{memq}:
@example
@group
-(member (list 2) '((1) (2))) ; @r{@code{(list 2)} and @code{(2)} are @code{equal}.}
+(member '(2) '((1) (2))) ; @r{@code{(2)} and @code{(2)} are @code{equal}.}
@result{} ((2))
@end group
@group
-(memq (list 2) '((1) (2))) ; @r{@code{(list 2)} and @code{(2)} are not @code{eq}.}
- @result{} nil
+(memq '(2) '((1) (2))) ; @r{The two @code{(2)}s need not be @code{eq}.}
+ @result{} @r{Unspecified; might be @code{nil} or @code{(2)}.}
@end group
@group
;; @r{Two strings with the same contents are @code{equal}.}
@@ -1626,7 +1626,7 @@ keys may not be symbols:
("compound leaves" . horsechestnut)))
(assq "simple leaves" leaves)
- @result{} @r{Unspecified; might be @code{nil} or non-@code{nil}.}
+ @result{} @r{Unspecified; might be @code{nil} or @code{("simple leaves" . oak)}.}
(assoc "simple leaves" leaves)
@result{} ("simple leaves" . oak)
@end smallexample
--
2.17.1
next prev parent reply other threads:[~2020-05-02 21:08 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200418200112.26900.1274@vcs0.savannah.gnu.org>
[not found] ` <20200418200114.85C8C20A2B@vcs0.savannah.gnu.org>
2020-04-18 21:24 ` emacs-27 eebfb72 1/2: Document constant vs mutable objects better Štěpán Němec
2020-04-18 21:57 ` Drew Adams
2020-04-19 20:37 ` Paul Eggert
2020-04-19 22:33 ` Štěpán Němec
2020-04-19 23:48 ` Paul Eggert
2020-04-20 0:18 ` Michael Heerdegen
2020-04-20 10:05 ` 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
2020-04-20 23:18 ` Michael Heerdegen
2020-04-22 17:54 ` Paul Eggert
2020-05-02 12:50 ` Štěpán Němec
2020-05-02 21:08 ` Paul Eggert [this message]
2020-04-20 0:16 ` Michael Heerdegen
2020-04-21 1:48 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8d7d73a2-e0c2-c43f-1125-534493752c91@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=emacs-devel@gnu.org \
--cc=michael_heerdegen@web.de \
--cc=stepnem@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.