[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: |
Thu, 06 Aug 2015 17:31:29 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) |
> 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.
You can't "make it impossible".
So, IIUC you want to signal errors for invalid maps.
> (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, now you don't want to signal errors for invalid maps?
Make up your mind.
> So you have to do
> (delq nil (mapcar #'car-safe '((a) (b 1) (c . 2) d)))
No: ((a) (b 1) (c . 2) d) is an invalid map, and it's perfectly OK (tho
not mandatory either) to signal an error when faced with such a thing.
> 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.
Reality check: Have you looked at the definition of hash-table-keys?
Better yet: have you looked at how often hash-table-keys is used?
The efficiency of map-keys is largely irrelevant.
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?
alists can be functional, whereas hash-tables are by nature imperative.
For example,
(cons (cons k v) m)
returns a new alist with a new mapping from "k" to "v" without changing
the map "m". Whereas after
(puthash k v m)
"m" has necessarily been modified.
Stefan
- RE: plists, alists, and hashtables, (continued)
- RE: plists, alists, and hashtables, Drew Adams, 2015/08/06
- Re: plists, alists, and hashtables, Ted Zlatanov, 2015/08/06
- Re: plists, alists, and hashtables, Pascal J. Bourguignon, 2015/08/06
- Re: plists, alists, and hashtables, Stefan Monnier, 2015/08/06
- RE: plists, alists, and hashtables, Drew Adams, 2015/08/05
Re: plists, alists, and hashtables, Stefan Monnier, 2015/08/06
Message not available
Message not available
- Re: plists, alists, and hashtables, Ted Zlatanov, 2015/08/06
- Re: plists, alists, and hashtables,
Stefan Monnier <=
- Re: plists, alists, and hashtables, Ted Zlatanov, 2015/08/06
- Re: plists, alists, and hashtables, Pascal J. Bourguignon, 2015/08/07
- Re: plists, alists, and hashtables, Stefan Monnier, 2015/08/07
- Message not available
- Re: plists, alists, and hashtables, Pascal J. Bourguignon, 2015/08/07
- Re: plists, alists, and hashtables, Stefan Monnier, 2015/08/08
- Re: plists, alists, and hashtables, Rusi, 2015/08/08
Re: plists, alists, and hashtables, Pascal J. Bourguignon, 2015/08/06
Re: plists, alists, and hashtables, Ted Zlatanov, 2015/08/06
Re: plists, alists, and hashtables, Pascal J. Bourguignon, 2015/08/07
Re: plists, alists, and hashtables, Ted Zlatanov, 2015/08/07