From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: "50110@debbugs.gnu.org" <50110@debbugs.gnu.org>
Subject: bug#50110: [External] : Re: bug#50110: 26.3; Doc of `assoc': TESTFN optional arg
Date: Wed, 18 Aug 2021 18:41:00 +0000 [thread overview]
Message-ID: <SJ0PR10MB5488C31D000EE8A8131881F3F3FF9@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <83y28y3anl.fsf@gnu.org>
> > Neither the `assoc' doc string nor the Elisp manual, node `Association
> > Lists' explains the order of the args that get passed to TESTFN.
>
> It's a function that tests 2 objects for equality, so why does the
> order matter?
>
> > It's just as reasonable to expect that the pattern is the first arg to
> > TESTFN, instead of, as is actually the case, the second arg.
>
> There's no "pattern" in the doc string, so I don't think I understand
> what you are describing here.
I gave examples. What part is unclear? To know how to use
`string-match-p' for testing you need to know the arg order
for TESTFN. The arg order matters for `string-match-p'.
IMO, it's an arbitrary predicate that's applied to 2 args,
one of which is the car of an alist element. It's not
necessarily an _equality_ predicate. You're may disagree,
but I think it would be more helpful to document which
TESTFN arg corresponds to the alist element cars.
FWIW, here's a user who ran directly into this doc problem,
which motivated this doc bug report:
https://emacs.stackexchange.com/q/68172/105
FWIW2, Common Lisp specifies the order, and in fact it is
the reverse of the order used by TESTFN in Elisp. See here:
https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node141.html#SECTION001800000000000000000
This text:
In the following function descriptions, an element x of a
sequence "satisfies the test" if any of the following holds:
* A basic function was called, TESTFN was specified by the
keyword :test, and (funcall TESTFN item (KEYFN x)) is true.
This would mean you would pass just predicate `string-match-p',
not (lambda (x y) (string-match-p y x)), as TESTFN for the
example. (Here, KEYFN would be the default, `car'.)
next prev parent reply other threads:[~2021-08-18 18:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-18 17:36 bug#50110: 26.3; Doc of `assoc': TESTFN optional arg Drew Adams
2021-08-18 17:50 ` Eli Zaretskii
2021-08-18 18:41 ` Drew Adams [this message]
2021-08-18 19:08 ` bug#50110: [External] : " Eli Zaretskii
2021-08-18 19:49 ` Drew Adams
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=SJ0PR10MB5488C31D000EE8A8131881F3F3FF9@SJ0PR10MB5488.namprd10.prod.outlook.com \
--to=drew.adams@oracle.com \
--cc=50110@debbugs.gnu.org \
--cc=eliz@gnu.org \
/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.