unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: "Basil L. Contovounesios" <contovob@tcd.ie>
Cc: Michael Heerdegen <michael_heerdegen@web.de>,
	dalanicolai <dalanicolai@gmail.com>,
	"47368@debbugs.gnu.org" <47368@debbugs.gnu.org>
Subject: bug#47368: [External] : bug#47368: 28.0.50; map-elt returns nil without "deprecated" TESTFN
Date: Fri, 26 Mar 2021 22:40:34 +0000	[thread overview]
Message-ID: <SA2PR10MB44741DCD3F1F1C4174FF4A10F3619@SA2PR10MB4474.namprd10.prod.outlook.com> (raw)
In-Reply-To: <87k0pty89m.fsf@tcd.ie>

> > Nothing about eq being the default, and nothing about
> > testing being also possible with the others you mention.
> >
> > Not only that, but the doc string says that TESTFN
> > is deprecated, but there's no other mention of TESTFN.
> >
> > What's TESTFN?  Where is it specified?  It's not part
> > of the function signature that's shown.  How can you
> > refer to it if there's no indication anywhere here of
> > what it is?  This makes no sense to me.
> 
> All of these points are already being discussed in this thread.

And yet in this thread you asked, seeming to suggest
that the doc here is fine as is:

  What would you like to see clarified in the documentation?

Seems pretty clear that this doc has more than one
problem, as I guess (hope) you acknowledge now.

If the function handles different kinds of data
(alists, hash tables, ... whatnot), and if its
behavior can depend on an equality predicate that
it can't know (can't even be passed as an arg),
then _that_, at the very least, should be stated
in the doc.

I'd think that if a test function _can_ be used for
at least some types of data, such as alists, then it
should be allowed as an optional arg.

Just because a function is generic, that doesn't mean
it has to always act with lowest-common-denominator
behavior.  A hash table has a given comparer.  But so
what?

Is `eq' the _default_ comparer, or is it the only one
for some data types?

  "its default depends on the MAP argument".

Maybe that too isn't generic enough?  If `eq' is all
that's allowed for some types then it makes no sense
to speak of a "default" those cases.

You said:

  That's what the docstring is trying to warn about:
  alists default to testing with eq, but can also use
  eql, equal, or anything else.

  Hash tables, OTOH, are limited to the test function
  that they were created with.

  So TESTFN doesn't always work as expected depending
  on the map type.

Why not allow TESTFN, and state that it applies only
to some types (naming some of them)?  Why cripple it
just because it's limited for some types?

Are you sure deprecating TESTFN was a great idea?

If it will remain deprecated, then at least add a
statement like what you wrote (above), to the doc.

And let users know how to use other than `eq' with
an alist etc., since you tell them that `eq' is
only the default and they can use other comparers.

And especially if the types are limited to alist,
hash table, and array, just _how_ a key is found
should be specified.  It makes no sense (to me)
for the doc to say only "If KEY is found".

FWIW, a cursory look at the code suggests the type
can also be a plist, but the doc currently mentions
only the other 3 types.  That too seems wrong.





  reply	other threads:[~2021-03-26 22:40 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-24 22:52 bug#47368: 28.0.50; map-elt returns nil without "deprecated" TESTFN dalanicolai
2021-03-24 23:24 ` Basil L. Contovounesios
2021-03-25  2:39   ` Michael Heerdegen
2021-03-25 14:48     ` dalanicolai
2021-03-25 15:33     ` bug#47368: [External] : " Drew Adams
2021-03-26 18:47       ` Basil L. Contovounesios
2021-03-26 20:04         ` Drew Adams
2021-03-26 20:23           ` Basil L. Contovounesios
2021-03-26 22:40             ` Drew Adams [this message]
2021-03-26 22:59               ` Basil L. Contovounesios
2021-03-26  3:59     ` Michael Heerdegen
2021-03-26  7:38       ` dalanicolai
2021-03-26 13:31       ` Stefan Monnier
2021-03-26 15:32         ` dalanicolai
2021-03-26 18:57         ` Basil L. Contovounesios
2021-03-26 23:18           ` Michael Heerdegen
2021-03-27 20:37           ` Basil L. Contovounesios
2021-03-26 23:23         ` Michael Heerdegen
2021-03-26 18:58     ` Basil L. Contovounesios
2021-07-21 15:34 ` Adam Porter
2021-07-22  2:15   ` Michael Heerdegen
2021-07-31  2:15     ` Michael Heerdegen
2021-09-13 14:06       ` Adam Porter
2021-09-14 14:40         ` Michael Heerdegen
2021-09-14 20:22           ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-15  0:48             ` Michael Heerdegen
2021-09-15  9:26               ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-15 12:39               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-15 21:53                 ` Michael Heerdegen
2021-09-15 12:50             ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-15 21:55               ` Michael Heerdegen
2021-09-21 12:42                 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors

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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=SA2PR10MB44741DCD3F1F1C4174FF4A10F3619@SA2PR10MB4474.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=47368@debbugs.gnu.org \
    --cc=contovob@tcd.ie \
    --cc=dalanicolai@gmail.com \
    --cc=michael_heerdegen@web.de \
    /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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).