unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: 45539@debbugs.gnu.org
Subject: bug#45539: 26.3; `add-to-ordered-list': Add optional arg for :test predicate for hash table
Date: Tue, 29 Dec 2020 23:01:03 -0800 (PST)	[thread overview]
Message-ID: <64015d41-a84f-4ff6-a5a1-ab5d92aa20e5@default> (raw)
In-Reply-To: <87y2hgosxo.fsf@gnus.org>

> > Please consider adding an optional arg TEST-PREDICATE, which will be
> > passed to the hash table (and which will default to `eq').
> 
> Since the ordering is hard-coded to `<', allowing the things being
> compared are presumably all numbers, so allowing specifying the
> comparison function doesn't make much sense.
> 
> However, using `eq' for numbers doesn't make much sense, either -- `eql'
> would be better.  Looking at the in-tree usages, switching to `eql'
> shouldn't make much difference, so I've done the daring thing and
> switched to `eql'.

I don't understand.  One of us is confused, I think.

What does the :test predicate for the hash table have to do with the order of elements in the list?

This is about letting you specify how the hash table is configured, by passing a TEST predicate arg to `add-to-ordered-list', which is just passed to the code implementing the hash table.  The purpose of the hash table's :test predicate is only to determine whether a hash-table item is already present, and if so, get its value using the item as key.

The code is currently hard-coded to use `eq' for :test, which works fine for symbol hash-table data, hence for symbol elements of the list.  But it doesn't work fine for, say, string list elements.  (And it wouldn't work well for numeric list elements, for which a :test of `eql' would be better.)

But in all cases, :test is about comparing the list elements, not their associated "order" in the list.

The things being compared are not numbers, they are the list elements.  The hash table is not used in any way for ordering the list.  The hash table hashes list elements (which can be anything) as the hash-table keys, and the order of those elements in the list (which are numeric) as the "order" values of the list elements.  When an entry is added to a hash table, it's the key, not the value, that's compared against other keys, using :test.

(elisp) `Creating Hash' says, for example:

':test TEST'
  This specifies the method of key lookup for this hash table.
  The default is 'eql'; 'eq' and 'equal' are other alternatives:

  'eql'
       Keys which are numbers are the same if they are 'equal',
       that is, if they are equal in value and either both are
       integers or both are floating point; otherwise, two
       distinct objects are never the same.

  'eq'
       Any two distinct Lisp objects are different as keys.

  'equal'
       Two Lisp objects are the same, as keys, if they are equal
       according to 'equal'.

In my understanding, :test is all about comparing hash-table keys, not values.  The hash table implements an association of ordered-list elements (the keys) with their orders in the list (the values).

This is about letting any kind of list elements to be in an "ordered list".  In the case of the example question, the list elements would be strings.  (Their orders in the list would be numbers.)  For string elements a :test of `equal' (or even `string=') makes sense and `eq' makes no sense.





  reply	other threads:[~2020-12-30  7:01 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-29 21:04 bug#45539: 26.3; `add-to-ordered-list': Add optional arg for :test predicate for hash table Drew Adams
2020-12-30  3:48 ` Lars Ingebrigtsen
2020-12-30  7:01   ` Drew Adams [this message]
2020-12-30  7:07     ` Lars Ingebrigtsen
2020-12-30  8:43       ` Drew Adams
2020-12-30 17:55         ` Drew Adams
2020-12-31  3:55           ` Lars Ingebrigtsen
2020-12-31  4:30             ` Lars Ingebrigtsen
2020-12-31  5:47               ` Drew Adams
2020-12-31 16:40                 ` Drew Adams
2020-12-31  5:34             ` 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

  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=64015d41-a84f-4ff6-a5a1-ab5d92aa20e5@default \
    --to=drew.adams@oracle.com \
    --cc=45539@debbugs.gnu.org \
    --cc=larsi@gnus.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 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).