all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#50110: 26.3; Doc of `assoc': TESTFN optional arg
@ 2021-08-18 17:36 Drew Adams
  2021-08-18 17:50 ` Eli Zaretskii
  0 siblings, 1 reply; 5+ messages in thread
From: Drew Adams @ 2021-08-18 17:36 UTC (permalink / raw)
  To: 50110

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






^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#50110: 26.3; Doc of `assoc': TESTFN optional arg
  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   ` bug#50110: [External] : " Drew Adams
  0 siblings, 1 reply; 5+ messages in thread
From: Eli Zaretskii @ 2021-08-18 17:50 UTC (permalink / raw)
  To: Drew Adams; +Cc: 50110

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





^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#50110: [External] : Re: bug#50110: 26.3; Doc of `assoc': TESTFN optional arg
  2021-08-18 17:50 ` Eli Zaretskii
@ 2021-08-18 18:41   ` Drew Adams
  2021-08-18 19:08     ` Eli Zaretskii
  0 siblings, 1 reply; 5+ messages in thread
From: Drew Adams @ 2021-08-18 18:41 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 50110@debbugs.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'.)





^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#50110: [External] : Re: bug#50110: 26.3; Doc of `assoc': TESTFN optional arg
  2021-08-18 18:41   ` bug#50110: [External] : " Drew Adams
@ 2021-08-18 19:08     ` Eli Zaretskii
  2021-08-18 19:49       ` Drew Adams
  0 siblings, 1 reply; 5+ messages in thread
From: Eli Zaretskii @ 2021-08-18 19:08 UTC (permalink / raw)
  To: Drew Adams; +Cc: 50110-done

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





^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#50110: [External] : Re: bug#50110: 26.3; Doc of `assoc': TESTFN optional arg
  2021-08-18 19:08     ` Eli Zaretskii
@ 2021-08-18 19:49       ` Drew Adams
  0 siblings, 0 replies; 5+ messages in thread
From: Drew Adams @ 2021-08-18 19:49 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 50110-done@debbugs.gnu.org

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

Thank you.





^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-08-18 19:49 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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   ` bug#50110: [External] : " Drew Adams
2021-08-18 19:08     ` Eli Zaretskii
2021-08-18 19:49       ` Drew Adams

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.