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 21:53:36 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87lhdnsw2n.fsf@lifelogs.com> 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 1438912519 10964 80.91.229.3 (7 Aug 2015 01:55:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 7 Aug 2015 01:55:19 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Aug 07 03:55:19 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 1ZNWsQ-0005bV-Ga for geh-help-gnu-emacs@m.gmane.org; Fri, 07 Aug 2015 03:55:18 +0200 Original-Received: from localhost ([::1]:47508 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNWsP-0002Oc-Pb for geh-help-gnu-emacs@m.gmane.org; Thu, 06 Aug 2015 21:55:17 -0400 Original-Path: usenet.stanford.edu!news.kjsl.com!feeder.erje.net!1.eu.feeder.erje.net!news.albasani.net!.POSTED!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 53 Original-X-Trace: news.albasani.net 4a25EhrmNumpjK+wwY/44rlbjS/ZBy4L9XmR+nAX4N9Kt0EkSDu5C5A2m8phAFBDQbt1uPf6SIu7n/RJIun8fw== Original-NNTP-Posting-Date: Fri, 7 Aug 2015 01:53:39 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="GpKs58SuUYjEm3TCzmoqdZ6Xqpx5ilIJXtbJope2JdOA1lD1MnjnGy6j6DoAJBwb5qrrNsmTxF41kA3Y1VElNu7amfdm2Mv6v++W4akBVBdSE283MD4lE+Tt7xqZgyAl"; 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:sltiOeveSNu/CDFrHhMUchIb6IA= sha1:8EjC1KaP7/shQM4nHrfGhWnsPBI= Original-Xref: usenet.stanford.edu gnu.emacs.help:214024 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:106309 Archived-At: On Thu, 06 Aug 2015 17:31:29 -0400 Stefan Monnier 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