bug#50110: 26.3; Doc of `assoc': TESTFN optional arg

bug#50110: 26.3; Doc of `assoc': TESTFN optional arg

[Drew Adams]

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

bug#50110: 26.3; Doc of `assoc': TESTFN optional arg

[Eli Zaretskii]

> From: Drew Adams <drew.adams@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.

bug#50110: [External] : Re: bug#50110: 26.3; Doc of `assoc': TESTFN optional arg

[Drew Adams]

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

bug#50110: [External] : Re: bug#50110: 26.3; Doc of `assoc': TESTFN optional arg

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "50110@debbugs.gnu.org" <50110@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.

bug#50110: [External] : Re: bug#50110: 26.3; Doc of `assoc': TESTFN optional arg

[Drew Adams]

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

Thank you.