bug#30458: 26.0; `ucs-names': No reverse lookup function now

bug#30458: 26.0; `ucs-names': No reverse lookup function now

[Drew Adams]

Before Emacs 26, `ucs-names' was an alist.  That meant that you could
not only look up a character, given its name or code, but you could also
easily look up a character name, given the character:

(car (rassq CHARACTER (ucs-names)))

How is this done now, with (ucs-names) returning a hash table?

There is now a function `char-from-name', to replace the former forward
alist lookup (car (assoc CHAR-NAME (ucs-names))).  But there doesn't
seem to be any reverse lookup now for `ucs-names' (e.g. `char-name' or
`char-name-from-char').

Seems like it should be possible to have such a reverse-lookup function
for any hash table (perhaps coded in C).

Sure, just like an alist, a hash table can have multiple keys that have
the same value.  And the order in a hash table is undefined, so when
there are multiple keys for the same value, a function that gives you
the key when you pass it the value can only give you one of those keys.
But that might be better than nothing.

Another possibility would be to have a function that returns all keys
that have the same value.

For example, naively (with lexical-binding):

(defun get-hash-keys (value hash-table &optional value-test-function)
  "Return a list of keys associated with VALUE in HASH-TABLE.
Optional arg VALUE-TEST-FUNCTION (default `equal') is the equality
predicate used to compare values."
  (setq value-test-function  (or value-test-function  #'equal))
  (let ((keys  ()))
    (maphash (lambda (key val)
               (when (funcall value-test-function val value)
                 (push key keys)))
             hash-table)
    keys))

Then:

(get-hash-keys (char-from-name "GREEK SMALL LETTER LAMBDA")
               (ucs-names))

returns ("GREEK SMALL LETTER LAMBDA" "GREEK SMALL LETTER LAMDA").

And for example:

(defun get-a-hash-key (value hash-table &optional value-test-function)
  "Return a hash key associated with VALUE in HASH-TABLE.
If there is more than one such key then it is undefined which is
returned.
Optional arg VALUE-TEST-FUNCTION (default `equal') is the equality
predicate used to compare values."
  (setq value-test-function  (or value-test-function  #'equal))
  (catch 'get-a-hash-key
    (maphash (lambda (key val)
               (when (funcall value-test-function val value)
                 (throw 'get-a-hash-key key)))
             hash-table)
    nil))

Then:

(get-a-hash-key (char-from-name "GREEK SMALL LETTER LAMBDA")
                (ucs-names))

returns "GREEK SMALL LETTER LAMDA" (though one would probably prefer
"GREEK SMALL LETTER LAMBDA").

For the reverse-lookup functions (reverse of `char-from-name') for
a character we would have:

(defun char-names (character)
  "Return a list of the names for CHARACTER."
  (get-hash-keys character (ucs-names)))

(defun char-name (character)
  "Return a name for CHARACTER, from `ucs-names'."
  (get-a-hash-key character (ucs-names)))

Please consider adding such reverse-lookup functions for hash
tables (whether using such an implementation or something else),
and adding specific such functions for `ucs-names', to accompany
the forward-lookup function `char-from-name'.

In GNU Emacs 26.0.91 (build 1, x86_64-w64-mingw32)
 of 2018-01-22
Repository revision: 752fba992b793a74d202c9cfc3e1a92fd458e748
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static -g3''

bug#30458: 26.0; `ucs-names': No reverse lookup function now

[Andy Moreton]

On Wed 14 Feb 2018, Drew Adams wrote:

> Before Emacs 26, `ucs-names' was an alist.  That meant that you could
> not only look up a character, given its name or code, but you could also
> easily look up a character name, given the character:
>
> (car (rassq CHARACTER (ucs-names)))
>
> How is this done now, with (ucs-names) returning a hash table?
>
> There is now a function `char-from-name', to replace the former forward
> alist lookup (car (assoc CHAR-NAME (ucs-names))).  But there doesn't
> seem to be any reverse lookup now for `ucs-names' (e.g. `char-name' or
> `char-name-from-char').

Looking at the implementation of ucs-names, does get-char-code-property
do what you want ?

  (char-from-name "GREEK SMALL LETTER LAMBDA")
      => 955

  (char-from-name "GREEK SMALL LETTER LAMDA")
      => 955

  (get-char-code-property 955 'name)
      => "GREEK SMALL LETTER LAMDA"

  (get-char-code-property 955 'old-name)
      => "GREEK SMALL LETTER LAMBDA"

HTH,

    AndyM

bug#30458: 26.0; `ucs-names': No reverse lookup function now

[Drew Adams]

> > Before Emacs 26, `ucs-names' was an alist.  That meant that you could
> > not only look up a character, given its name or code, but you could
> > also easily look up a character name, given the character:
> >
> > (car (rassq CHARACTER (ucs-names)))
> >
> > How is this done now, with (ucs-names) returning a hash table?
> >
> > There is now a function `char-from-name', to replace the former forward
> > alist lookup (car (assoc CHAR-NAME (ucs-names))).  But there doesn't
> > seem to be any reverse lookup now for `ucs-names' (e.g. `char-name' or
> > `char-name-from-char').
> 
> Looking at the implementation of ucs-names, does get-char-code-property
> do what you want ?
> 
> (char-from-name "GREEK SMALL LETTER LAMBDA") => 955
> (char-from-name "GREEK SMALL LETTER LAMDA") => 955
> (get-char-code-property 955 'name) => "GREEK SMALL LETTER LAMDA"
> (get-char-code-property 955 'old-name) => "GREEK SMALL LETTER LAMBDA"

Yes, thanks.  I had forgotten about that function.

Still, I would ask to have general reverse-lookup functions
for a hash table, as well.  Would someone please retitle this
bug for that?

bug#30458: 26.0; `ucs-names': No reverse lookup function now

[Noam Postavsky]

retitle 30458 hash table reverse-lookup (get-keys VALUE TABLE) => KEYS
quit

Drew Adams <drew.adams@oracle.com> writes:

> Still, I would ask to have general reverse-lookup functions
> for a hash table, as well.  Would someone please retitle this
> bug for that?

bug#30458: hash table reverse-lookup (get-keys VALUE TABLE) => KEYS

[Lars Ingebrigtsen]

Drew Adams <drew.adams@oracle.com> writes:

> Still, I would ask to have general reverse-lookup functions
> for a hash table, as well.  Would someone please retitle this
> bug for that?

We have this now in the form of `map-filter' (and friends), so I'm
closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#30458: [External] : Re: bug#30458: hash table reverse-lookup (get-keys VALUE TABLE) => KEYS

[Drew Adams]

> > Still, I would ask to have general reverse-lookup functions
> > for a hash table, as well.  Would someone please retitle this
> > bug for that?
> 
> We have this now in the form of `map-filter' (and friends),
> so I'm closing this bug report.

It's fine that we have `map-filter' and friends.
But that doesn't really help very directly, or in
terms of discoverability.  It's easy to discover
`rassoc', given `assoc' (e.g., just use `apropos',
or look up `assoc' in the manual, or just look up
"association list").

Being able to realize this functionality "in the
form of `map-filter' (& friends)" isn't so helpful.

And has the _doc about hash tables_ been updated
to indicate just how to do a reverse lookup?

Node `Association Lists' of the Elisp manual tells
you about `assoc', `rassoc', and `assq' (and more)
together.  Why?  Because their doc belongs together.

If a similar/equivalent treatment hasn't been done
for hash tables - provide a direct function and fix
the doc - then I don't consider this bug to have
been fixed.  Instead, in that case it's just another
"won't fix".

The aim shouldn't be to find a reason to close bug
reports.  The aim should be to fix bugs.  If the bug
was really fixed, then thanks!  If not, no thanks.

Saying that one can program using this, that, and
the other thing (XYZ "and friends") to work around
the lack of some feature is no replacement for
providing that missing feature directly.

`rassoc' and `rassq' have been in Lisp since about
Day One.  There's a reason for that.