[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#28753: 25.3; Functions to get alist from hash table and vice versa
From: |
Drew Adams |
Subject: |
bug#28753: 25.3; Functions to get alist from hash table and vice versa |
Date: |
Wed, 11 Oct 2017 09:42:47 -0700 (PDT) |
> > > 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.