Re: new function proposal alist-to-hash

[Stefan Monnier <monnier@iro.umontreal.ca>]

> - I think is quite useful to be able to create in a concise and
>   explicit way nested hash tables. This is a common feature of many
>   "modern" languages.
>   Here both solutions compared:
>
> (alist-to-hash '((a . x)
> 		 (b . ((i . j)
> 		       (k . l)))
> 		 (c . y)))
>
> (map-into `((a . x)
> 	    (b . ,(map-into '((i . j)
> 			      (k . l))
> 			    'hash-table))
> 	    (c . y))
> 	  'hash-table)

Not sure I understand: if you only use it for immediate/literal data,
then I guess you could just use the #s(hash-table data (...)) syntax.
And for non-literal maps, this needs to somehow distinguish values that
are alists from others, like

    (map-into (mapcar (lambda (x)
                        (if (and (consp (cdr x)) (consp (cadr x)))
                            (cons (car x) (map-into (cdr x) 'hash-table))
                          x))
                      my-alist)
              'hash-table)

But I suspect that this is not frequently needed.
[ BTW, the above code is screaming for something like `map-values-apply`
  but which returns a *map* rather than a list.  ]

And if you really need this to apply recursively, it basically means
you don't have a map but a *tree* where each node is originally
implemented as an alist and which you want to transform into the same
tree where each node is now a hash-table.  Again, this is likely not
needed very frequently (and I suspect that each time it's needed, it
will have slightly different needs/constraints).

> - map-into does not let you tweak make-hash-table parameters.
>   This is especially a limitation regarding :test so is effectively a
>   solution to say ~50% of the use cases.

Yes, this is a very serious limitation of `map-into`.
I decided not to try to tackle it when I converted map.el to use
cl-defmethod, but I'd welcome help on this.


        Stefan