GNU bug report logs - #50110
26.3; Doc of `assoc': TESTFN optional arg

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 50110 in the body.
You can then email your comments to 50110 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: 26.3; Doc of `assoc': TESTFN optional arg
Date: Wed, 18 Aug 2021 17:36:11 +0000

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 just as reasonable to expect that the pattern is the first arg to
TESTFN, instead of, as is actually the case, the second arg.

E.g., one could suppose that this would work (return the first element):

(setq trees '(("pine" . "cones") ("oak" . "acorns")))

(assoc ".*ine" trees #'string-match-p)

But in fact this is what you need:

(assoc ".*ine" trees (lambda (x regexp) (string-match-p regexp x)))

Please consider documenting the arg order for TESTFN.

In GNU Emacs 26.3 (build 1, x86_64-w64-mingw32)
 of 2019-08-29
Repository revision: 96dd0196c28bc36779584e47fffcca433c9309cd
Windowing system distributor `Microsoft Corp.', version 10.0.19042
Configured using:
 `configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static -g3''

Message #8 received at 50110 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 50110 <at> debbugs.gnu.org
Subject: Re: bug#50110: 26.3; Doc of `assoc': TESTFN optional arg
Date: Wed, 18 Aug 2021 20:50:06 +0300

> From: Drew Adams <drew.adams <at> oracle.com>
> Date: Wed, 18 Aug 2021 17:36:11 +0000
> 
> 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.

Message #11 received at 50110 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "50110 <at> debbugs.gnu.org" <50110 <at> debbugs.gnu.org>
Subject: RE: [External] : Re: bug#50110: 26.3; Doc of `assoc': TESTFN optional
 arg
Date: Wed, 18 Aug 2021 18:41:00 +0000

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

Message #16 received at 50110-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 50110-done <at> debbugs.gnu.org
Subject: Re: [External] : Re: bug#50110: 26.3; Doc of `assoc': TESTFN optional
 arg
Date: Wed, 18 Aug 2021 22:08:53 +0300

> From: Drew Adams <drew.adams <at> oracle.com>
> CC: "50110 <at> debbugs.gnu.org" <50110 <at> debbugs.gnu.org>
> Date: Wed, 18 Aug 2021 18:41:00 +0000
> 
> > > 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'.

OK, I added description of how TESTFN is called.

Message #19 received at 50110-done <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "50110-done <at> debbugs.gnu.org" <50110-done <at> debbugs.gnu.org>
Subject: RE: [External] : Re: bug#50110: 26.3; Doc of `assoc': TESTFN optional
 arg
Date: Wed, 18 Aug 2021 19:49:25 +0000

> OK, I added description of how TESTFN is called.

Thank you.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.