Re: plists, alists, and hashtables

[Ted Zlatanov <tzz@lifelogs.com>]

On Thu, 06 Aug 2015 17:31:29 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> So, IIUC you want to signal errors for invalid maps.

That's what I meant, yes.  The syntax to specify an invalid map would be
invalid at the reader level and generate an error when the source code
is parsed.

>> (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.

SM> So, now you don't want to signal errors for invalid maps?
SM> Make up your mind.

I am showing how extracting the keys of an alist can generate *runtime*
errors, when the alist has already been read in.  Which makes actual
maps more appealing, I thought, because they could avoid that problem at
the reader level.

SM> Reality check: Have you looked at the definition of hash-table-keys?
SM> Better yet: have you looked at how often hash-table-keys is used?
SM> The efficiency of map-keys is largely irrelevant.

Right. I agree. My point was different: there is no "keys" function for
alists and plists.  Keys in those two formats are a convention.

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?

SM> alists can be functional, whereas hash-tables are by nature imperative.
SM> For example,

SM>    (cons (cons k v) m)

SM> returns a new alist with a new mapping from "k" to "v" without changing
SM> the map "m".  Whereas after

SM>    (puthash k v m)

SM> "m" has necessarily been modified.

I certainly see the advantages of appending instead of modifying in
place. I think that's an artifact of the current hashtable API, not a
fundamental property of maps or hashtables. Would it be useful if, in
addition to the reader syntax, "maps" (backed by hashtables or something
else) were made cons-able as you describe? Or is that fundamentally
impossible in your opinion?

Ted