From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.help Subject: Re: plists, alists, and hashtables Date: Thu, 06 Aug 2015 17:31:29 -0400 Organization: A noiseless patient Spider Message-ID: References: <876150vwaa.fsf@mbork.pl> <873803x5q4.fsf@kuiper.lan.informatimago.com> <87a8u7we9s.fsf_-_@lifelogs.com> <877fp8t9ru.fsf@lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1438896933 10971 80.91.229.3 (6 Aug 2015 21:35:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Aug 2015 21:35:33 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Aug 06 23:35:33 2015 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZNSp2-0003i0-SZ for geh-help-gnu-emacs@m.gmane.org; Thu, 06 Aug 2015 23:35:33 +0200 Original-Received: from localhost ([::1]:46807 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNSp2-0002r3-0j for geh-help-gnu-emacs@m.gmane.org; Thu, 06 Aug 2015 17:35:32 -0400 Original-Path: usenet.stanford.edu!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 51 Injection-Info: mx02.eternal-september.org; posting-host="81077855a1b79cdd446ddfce5f593b54"; logging-data="25534"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18Ojdygu8maKZCsKe7ZQ/Bw" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:dE2s0Z2XW3ZDLyuIURWLWvUHzp4= sha1:/DWfnxHdyMx5P3AygpcFiVUgBEM= Original-Xref: usenet.stanford.edu gnu.emacs.help:214020 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:106305 Archived-At: > 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