[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: plists, alists, and hashtables
From: |
Ted Zlatanov |
Subject: |
Re: plists, alists, and hashtables |
Date: |
Thu, 06 Aug 2015 21:53:36 -0400 |
User-agent: |
Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) |
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
- Re: plists, alists, and hashtables, (continued)
- 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, 2015/08/06
- Re: plists, alists, and hashtables,
Ted Zlatanov <=
- 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
Re: plists, alists, and hashtables, Pascal J. Bourguignon, 2015/08/07