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 22:14:24 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87h9obsv3z.fsf@lifelogs.com> References: <876150vwaa.fsf@mbork.pl> <873803x5q4.fsf@kuiper.lan.informatimago.com> <87a8u7we9s.fsf_-_@lifelogs.com> <877fp8t9ru.fsf@lifelogs.com> <87h9ocm02t.fsf@kuiper.lan.informatimago.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1438913720 31330 80.91.229.3 (7 Aug 2015 02:15:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 7 Aug 2015 02:15:20 +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 04:15: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 1ZNXBn-0005rE-6r for geh-help-gnu-emacs@m.gmane.org; Fri, 07 Aug 2015 04:15:19 +0200 Original-Received: from localhost ([::1]:47558 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNXBl-00047P-W5 for geh-help-gnu-emacs@m.gmane.org; Thu, 06 Aug 2015 22:15:17 -0400 Original-Path: usenet.stanford.edu!goblin1!goblin.stu.neva.ru!news.albasani.net!.POSTED!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 95 Original-X-Trace: news.albasani.net UDYDESSLDXDLh89/OEDiaxgV1dnVL4bUPz8JfzxckUeltVxyRXCKP4nV4dBYOdFNYP7/kqdsuc/J1lOIrrUDgw== Original-NNTP-Posting-Date: Fri, 7 Aug 2015 02:14:24 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="r5+sVmotjcScHlNNlJZZsH0Ecqh61kP2lRCidJ8VeZH8ZPKtZ9zj80GmrkDhHp0KZJqLnqf7RFc9x6XR/+WLkRpbbizjRvlnP+8vJSHWuBRMsxYdF5fNTO2g7u2E9EKk"; 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:rRSz00Rs17lzAbsRYdlAMbTesmA= sha1:Mo4j+LzoSJml+m0rT5iTHfaaNAE= Original-Xref: usenet.stanford.edu gnu.emacs.help:214025 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:106310 Archived-At: On Fri, 07 Aug 2015 02:08:58 +0200 "Pascal J. Bourguignon" wrote: PJB> Ted Zlatanov writes: >> 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. PJB> I understand that, and I cannot advise more strongly that you add PJB> newlines and indent your data to clearly show it. PJB> (hash-table k1 v1 PJB> kkkk2 v2 PJB> k3 vvvvvv3) I don't think it's good to force the programmer to reformat their code because the syntax doesn't do the right thing. PJB> Also, I would admit that using parentheses around the entries could help PJB> editing the data structure, since that allows adding or removing entries PJB> easily with a structural editor like emacs+paredit. PJB> (mhash-table (k1 v1) PJB> (kkkk2 v2) PJB> (k3 vvvvvv3)) PJB> It works well enough for a macro (eg. let), but for a function it is a PJB> real bother I think that's good enough in the `let' format, as a macro. The syntactic shortcut of creating keys without a cell with a null value is nice too. Can we agree that this is a good syntax and move back to discussing Unicode markers again? :) >> The second part of my question was whether Customize support for >> hashtables would make them more approachable and useful. PJB> This could definitely help. OK, I'm glad you agree. Maybe that discrete work would be generally helpful regardless of the rest of this discussion. PJB> Well, as mentionned before, if you abstract away a given type of maps: PJB> - you may hide the costs, and that would lead to bad results, PJB> - you would impose one kind of data structure usage (mutable hash or PJB> immutable a-list or mutable a-lists or llrb-trees? etc) PJB> - or if you don't and make it adaptative, we observe that there's PJB> actually very little gain obtained, (because it takes time to convert PJB> the data structures, and therefore it's hard to amortize that cost). I see your point. It connects with Stefan's point about cons-ing alists and plists because they're persistent. Thank you for stating it well. PJB> If you don't believe that, you can always implement a library to provide PJB> a common API over various dictionaries. I did just that in CL: PJB> https://gitlab.com/com-informatimago/com-informatimago/blob/master/common-lisp/cesarum/dictionary.lisp PJB> (sorry, I've not written the automatic adaptative code yet). PJB> Let me just say that this is not the API I reach first when I write lisp PJB> code. Just use a-lists or hash-tables directly, depending on the PJB> circumstances determined at program-writting time. OK, and your experience confirms the answer to my question. This is very helpful to countermand my intuition, which is perhaps guided too much by the other languages I use. PJB> Notice that as mentionned before, the question here is whether that PJB> should be included into the emacs lisp language, or whether that should PJB> be defined as a user library. PJB> As a user library nobody will say that it's a bad idea and that it PJB> cannot have its usage in some program. Yup, I understand. I'll look into making it. PJB> And this is why we feel the lack of reader macros, since that would PJB> clearly allow you to write a new syntax in a user library, instead of PJB> having to beg it from the emacs lisp language itself. Is this work already planned? How much of it must be done to accomplish what I want, a library that lets me say `{ "k1": "v1" }' (giving JSON syntax as an example) and translates it to the correct #s(hash-table ...) serialization? Together with the Customize support for hashtables, I think we can agree these would be nice usability improvements. Stefan also mentioned there could be performance optimizations for hashtables themselves. I think that's a good direction too. Ted