Re: plists, alists, and hashtables

[Ted Zlatanov]

On Thu, 06 Aug 2015 15:12:54 -0400 Stefan Monnier <monnier@iro.umontreal.ca> 
wrote: 

>> (alist-get 'd '((a) (b 1) (c . 2) d)) -> nil ; no error

SM> Just like Javascript, Elisp often errs on "don't signal an error" when
SM> it bumps into something that's of the wrong type.  I don't like it very
SM> much, but it has its advantages as well.

Sure, absolutely.  I'm trying to say that a better read syntax for maps
could avoid that altogether by making it impossible to specify something
like the alist above.

>> For instance, the hashtable keys are unambiguously
>> (hash-table-keys my-hashtable) and there's no looping or parsing.

SM> For instance, the alist's keys are unambiguously (mapcar #'car my-alist) 
SM> and there's no looping or parsing.

(mapcar #'car '((a) (b 1) (c . 2) d))
-> Debugger entered--Lisp error: (wrong-type-argument listp d)

...and that's just a simple edge case.

So you have to do

(delq nil (mapcar #'car-safe '((a) (b 1) (c . 2) d)))

When the backend implementation is also the frontend, as with alists,
you have to go through the whole alist to collect the keys. That's the
access-time looping and parsing I mean. By contrast, the hashtable
implementation (whether it does it now or not) can keep the list of keys
and update it only when the data is modified.  At access time, the keys
are instantly available.

SM> [ And no, please don't go and add plist-keys to subr-x.el.  ]

Heh, no, `loop' works well enough for me :)

SM> More specifically, I highly doubt that a special «k1 v1 k2 v2 ...»
SM> syntax for hash-tables would make much difference compared to
SM> (hash-table k1 v1 k2 v2 ...) which you can get today with a very simple
SM> `hash-table' macro.  I mean, you'd still have to say (gethash k m),
SM> whereas you'd probably want something like m.k, etc...

Maybe the macro is good enough, but I think the keys and values have to
be clearly separated from each other and from other cells to make it
visually useful.  The key for me is that I'm not looking to make
hashtables themselves more prominent, but to give ELisp users a way to
read and write maps more clearly and in a way that maps more closely to
a true map data type (which I thought the hashtable was).

The second part of my question was whether Customize support for
hashtables would make them more approachable and useful.

SM> More importantly, mathematical maps are persistent, whereas your
SM> apparently favorite implementation (the hash-table) is not persistent,
SM> contrary to (e.g.) alists.

I am not sure what you mean.  Perhaps it's a problem with the
terminology.  Could you explain?

Ted