From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.help Subject: Re: plists, alists, and hashtables Date: Thu, 06 Aug 2015 16:57:41 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <877fp8t9ru.fsf@lifelogs.com> References: <876150vwaa.fsf@mbork.pl> <873803x5q4.fsf@kuiper.lan.informatimago.com> <87a8u7we9s.fsf_-_@lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1438894831 10996 80.91.229.3 (6 Aug 2015 21:00:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Aug 2015 21:00:31 +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:00:30 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 1ZNSH4-0000HL-OQ for geh-help-gnu-emacs@m.gmane.org; Thu, 06 Aug 2015 23:00:26 +0200 Original-Received: from localhost ([::1]:46668 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNSH4-0007gQ-2F for geh-help-gnu-emacs@m.gmane.org; Thu, 06 Aug 2015 17:00:26 -0400 Original-Path: usenet.stanford.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!news-2.dfn.de!news.dfn.de!feeder.erje.net!1.eu.feeder.erje.net!news.albasani.net!.POSTED!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 62 Original-X-Trace: news.albasani.net D/CIRHigaRw7RS6X1JduqCf/Ccu8hUMKJ20GB+S4nBbizWLJcVTaFMf+ohVFe7p5MME569eJXwAUV02AK8r0Rg== Original-NNTP-Posting-Date: Thu, 6 Aug 2015 20:57:41 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="CbmAd1EGzjNF6OGMyggix5q/VbDyKzfYkSF9/XwP4SrUd//StjT/ULtBe8oDkWKrzbDeMuKQWWFKG3NbFW8qJe95TYhVHXt6qxMvrJSRXHN7hxSk601NAydcHNJwN8G0"; mail-complaints-to="abuse@albasani.net" User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Cancel-Lock: sha1:4SKz/854hQmK3c+9Zr+0QNPc3Yw= sha1:tBLl5v/RquoEzupNpirGoxJ0wOY= Original-Xref: usenet.stanford.edu gnu.emacs.help:214016 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:106300 Archived-At: On Thu, 06 Aug 2015 15:12:54 -0400 Stefan Monnier wrote: >> (alist-get 'd '((a) (b 1) (c . 2) d)) -> nil ; no error SM> Just like Javascript, Elisp often errs on "don't signal an error" when SM> it bumps into something that's of the wrong type. I don't like it very SM> much, but it has its advantages as well. 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. >> For instance, the hashtable keys are unambiguously >> (hash-table-keys my-hashtable) and there's no looping or parsing. SM> For instance, the alist's keys are unambiguously (mapcar #'car my-alist) SM> and there's no looping or parsing. (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 you have to do (delq nil (mapcar #'car-safe '((a) (b 1) (c . 2) d))) 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. SM> [ And no, please don't go and add plist-keys to subr-x.el. ] Heh, no, `loop' works well enough for me :) SM> More specifically, I highly doubt that a special «k1 v1 k2 v2 ...» SM> syntax for hash-tables would make much difference compared to SM> (hash-table k1 v1 k2 v2 ...) which you can get today with a very simple SM> `hash-table' macro. I mean, you'd still have to say (gethash k m), SM> whereas you'd probably want something like m.k, etc... Maybe the macro is good enough, but I think the keys and values have to be clearly separated from each other and from other cells to make it visually useful. The key for me is that I'm not looking to make hashtables themselves more prominent, but to give ELisp users a way to read and write maps more clearly and in a way that maps more closely to a true map data type (which I thought the hashtable was). The second part of my question was whether Customize support for hashtables would make them more approachable and useful. 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? Ted