Re: plists, alists, and hashtables

[Ted Zlatanov <tzz@lifelogs.com>]

On Wed, 05 Aug 2015 08:12:22 +0200 "Pascal J. Bourguignon" <pjb@informatimago.com> wrote: 

PJB> What you are losing from sight is the fact that:

PJB> - a-lists are lists
PJB> - p-lists are lists
PJB> - lists are sequences
PJB> - lists are cons cells or nil

PJB> therefore any operator working on cons cells, on sequences, on lists,
PJB> can also work on p-lists and on a-lists.

Yes, I think the implicit advantage of everything being a list is well
understood amongst us.  But so is the disadvantage of treating
everything as a list.  The question is whether hashtables, an existing
ELisp map data type, could become more popular.

PJB> Unfortunately there are many more than 8 datastructures for which you
PJB> could want a specific syntax. 

You have to be specific about why we'd discuss or want these 8 data
structures, since the discussion was only about hashtables.

My original question was actually:
> I wonder, if hashtables had a better reader syntax (like plists or
> alists) and better Customize support, would they see wider use? Or is
> the historical baggage in tutorials and existing code too much at this
> point?

Hashtables in Emacs Lisp already have a read syntax, in fact: see
(info "(elisp) Hash Tables")

So maybe if that syntax could be a little less clumsy without breaking
the rest of ELisp, that would help?

For instance, `#s(hash-table)' will evaluate to an empty hashtable
already.  But typically you want to control the other parameters, so
this is what `make-hash-table' returns:

#s(hash-table size 65 test eql rehash-size 1.5 rehash-threshold 0.8 data ())

How do we make an easy syntax for that? I see only two major variations
of maps in ELisp; using `eql' or `equal' for keys. I can imagine some
unlikely cases where you'd want other equality comparisons for the keys,
like numeric equality, but I think over 95% of the cases will be covered
by just those two variations.

For instance, and this is just an example:

{{(a . b)}} ; hashtable with test `eql' mapping a to b
{(a . b)}   ; hashtable with test `equal' mapping a to b

And finally, if you could Customize hashtables, would that make it
easier to support them as first-class variables in packages? I think
so...

Ted