[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: plists, alists, and hashtables

From: Stefan Monnier
Subject: Re: plists, alists, and hashtables
Date: Fri, 07 Aug 2015 12:32:28 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

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

I'd estimate that it would catch 0.05% of the errors a bit earlier, yes.

> Right. I agree. My point was different: there is no "keys" function for
> alists and plists.

(mapcar #'car ...) *is* the "keys" function for alists.  You could
define it as `alist-keys', or use `map-keys' from map.el for that.
The only reason why it's never been defined so far is because (mapcar
#'car ...) is quite sufficient since extracting the list/set of keys of
a map is a rare operation.

> Keys in those two formats are a convention.

Yes but one you can rely on.

I think what you're getting at is that (core) Lisp is somewhat
"untyped", so alists/plists can't be distinguished from other data built
using cons-cells: only the user knows whether that cons cells is meant
to be an alist or a plist or something else.

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

There are persistent hash-tables, indeed, but they typically use some
kind of tree/trie rather than one big hashing array.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]