bug#28753: 25.3; Functions to get alist from hash table and vice versa

[Drew Adams <drew.adams@oracle.com>]

> > > Dunno whether functions like these might be useful.  I use something
> > > similar.  If you think they're useful, consider adding them.
> >
> > I think something very similar is provided by map.el: `map-into'.
> 
> Good to know.  Thx.

Actually, going from alist to hash table doesn't look so
useful with `map-into'.  A caller should be able to specify
the hash-table parameters (features), such as :test.

`map-into' should probably accept additional, keyword args,
which would be passed to `map--into-hash-table'.

I imagine that `map-into' is intended to be extended to
more than alists and hash tables eventually.  Otherwise,
dedicated functions for those two types, such as what I
suggested, would make as much (or more) sense.

Whether or not it will be so extended, it would be good
for `map-into' to accept additional args that would be
passed to the appropriate type-conversion helper functions.

If we just allowed an &rest ARGS parameter, that would
handle any types that might want to deal with additional
args.  But that would be less convenient than using
keyword args for a hash table.

We could I guess just pass ARGS along but define the
helper function (e.g. `map--into-hash-table') using
`cl-defun' with appropriate keyword args.  IOW, at the
`map-into' level nothing would be specified about ARGS,
but each conversion helper could define what kinds of
args it accepts.

(There's also `&allow-other-keys', but probably it
doesn't make much sense for `map-into' to define any
keyword args.)

In that case, the helper function should not be
"internal", and the use of `make-hash-table' keyword
args should be mentioned in its doc string.

Although simple lookup in an Elisp alist typically
uses only `assoc' or `assq' (or `rassoc' or `rassq'),
a program that _uses_ an alist might well make use
of a different equality test for its elements.  It
need not be limited to testing membership using
`assoc' or `assq'.

So while the alist to be converted to a hash table
might not, itself, have any fancy notion of a :test
function, the appropriate "equivalent" hash table in
some context might well need to define a particular
:test.

This is why it makes sense to allow conversion to a
hash table to give programmers an ability to specify
:test (and other hash-table features).

Note too that in Common Lisp `assoc' takes a :test arg.
`map-into' is designed for alists that use `cl-assoc'
as much as for those that use `assoc'.  Unlike a hash
table, however, an alist doesn't itself record ir
require any particular :test function, so `map-into'
can't transfer a hash-table :test to an alist that it
produces from a hash table.  So the existing `map-into'
for conversion to an alist is good enough.