From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Pascal J. Bourguignon" Newsgroups: gmane.emacs.help Subject: Re: plists, alists, and hashtables Date: Fri, 07 Aug 2015 02:23:40 +0200 Organization: Informatimago Message-ID: <87d1z0lzeb.fsf@kuiper.lan.informatimago.com> References: <876150vwaa.fsf@mbork.pl> <873803x5q4.fsf@kuiper.lan.informatimago.com> <87a8u7we9s.fsf_-_@lifelogs.com> <02f81836-554f-4bb4-873b-85c24e080e3d@googlegroups.com> <87614uqn5l.fsf@kuiper.lan.informatimago.com> <87d1z2ukw1.fsf@lifelogs.com> <878u9pps1c.fsf@kuiper.lan.informatimago.com> <87oailbn8t.fsf@lifelogs.com> <87vbcto2ya.fsf@kuiper.lan.informatimago.com> <87si7wtpib.fsf@lifelogs.com> <8737zwntla.fsf@kuiper.lan.informatimago.com> <871tfgt99k.fsf@lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1438907128 32233 80.91.229.3 (7 Aug 2015 00:25:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 7 Aug 2015 00:25:28 +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 02:25:24 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 1ZNVTN-00084h-BD for geh-help-gnu-emacs@m.gmane.org; Fri, 07 Aug 2015 02:25:21 +0200 Original-Received: from localhost ([::1]:47390 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNVTL-0006s7-FH for geh-help-gnu-emacs@m.gmane.org; Thu, 06 Aug 2015 20:25:19 -0400 Original-Path: usenet.stanford.edu!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 116 Original-X-Trace: individual.net 8B3vFevGR4q6w6+SPvpm5wDOWjtrvCUN1DMB+ccBTzF3nHHfxq Cancel-Lock: sha1:ZmFmNDZmMWQ5M2ZjNjQ0MjlhZGFkNTIzZWY0NGFmZTRlOWM4ZDBlZQ== sha1:njKseVV3JL2mxRvLgveCpUgvJC4= Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAQMAAABtzGvEAAAABlBMVEUAAAD///+l2Z/dAAAA oElEQVR4nK3OsRHCMAwF0O8YQufUNIQRGIAja9CxSA55AxZgFO4coMgYrEDDQZWPIlNAjwq9 033pbOBPtbXuB6PKNBn5gZkhGa86Z4x2wE67O+06WxGD/HCOGR0deY3f9Ijwwt7rNGNf6Oac l/GuZTF1wFGKiYYHKSFAkjIo1b6sCYS1sVmFhhhahKQssRjRT90ITWUk6vvK3RsPGs+M1RuR mV+hO/VvFAAAAABJRU5ErkJggg== X-Accept-Language: fr, es, en User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Original-Xref: usenet.stanford.edu gnu.emacs.help:214023 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:106308 Archived-At: Ted Zlatanov writes: > On Thu, 06 Aug 2015 20:46:09 +0200 "Pascal J. Bourguignon" wrote: > > PJB> Ted Zlatanov writes: > >>> OK, it's possible, but that's a terrible syntax. Maps should *look* >>> different from lists and their keys and values, in particular, should be >>> easily distinguished from each other. > > PJB> Why? > > Because I don't want to look at (a b c d e f g h) and count until I find > that g is a key and h is a value. That's dumb and leads to mistakes. But you never have (a b c d e f g h). You either have: (:a b :c d :e f :g h) or you have: (a b c d e f g h) Really, it is quite rare that the form and type of the keys be the same as for the values, so even when written on one line, there's no confusion. The only case where you would have the same form, is for an actual dictionary to translate words, or a map used to represent a discrete numeric function. (defvar *increment[4]* (dictionary 0 1 1 2 2 3 3 0)) (defvar *localize* (dictionary "hello" "bonjour" "bus" "car" "car" "voiture" "hide" "cache" "cache" "cachette")) could be confusing, but not: (defvar *increment[4]* (dictionary 0 1 1 2 2 3 3 0)) (defvar *localize* (dictionary "hello" "bonjour" "bus" "car" "car" "voiture" "hide" "cache" "cache" "cachette")) > PJB> Additionnal syntaxes can be useful, and should only be used, for end > PJB> users and DSL implementing a domain with pre-existing _extensive_ use of > PJB> that syntax. > > My claim, I guess, is that general ELisp programming involves an > extensive use of maps, so it could use a syntax for it. > > I am not making any philosophical claims about the essence of Lisp. Well, as mentionned before, if you abstract away a given type of maps: - you may hide the costs, and that would lead to bad results, - you would impose one kind of data structure usage (mutable hash or immutable a-list or mutable a-lists or llrb-trees? etc) - or if you don't and make it adaptative, we observe that there's actually very little gain obtained, (because it takes time to convert the data structures, and therefore it's hard to amortize that cost). And therefore the general conclusion is that it's not such a good idea to abstract away a higher level notion. Ie. the programmers must have the choice between hash-table and a-list or something else. If you don't believe that, you can always implement a library to provide a common API over various dictionaries. I did just that in CL: https://gitlab.com/com-informatimago/com-informatimago/blob/master/common-lisp/cesarum/dictionary.lisp (sorry, I've not written the automatic adaptative code yet). Let me just say that this is not the API I reach first when I write lisp code. Just use a-lists or hash-tables directly, depending on the circumstances determined at program-writting time. > PJB> But maps are not something out of this lisp world. They existed from > PJB> the start as a-list, then p-list and then hash-tables. They are a basic > PJB> data structure perfectly integrated to an algorithmic programming > PJB> language, and don't constitute a different, Domain Specific Language. > > I've given examples of why lists, in my opinion, don't make a good read > syntax for maps. If that's not enough to convince people, then it's not > a good idea. Notice that as mentionned before, the question here is whether that should be included into the emacs lisp language, or whether that should be defined as a user library. As a user library nobody will say that it's a bad idea and that it cannot have its usage in some program. What we reject, is the idea that it should be included in the emacs lisp language. And this is why we feel the lack of reader macros, since that would clearly allow you to write a new syntax in a user library, instead of having to beg it from the emacs lisp language itself. -- __Pascal Bourguignon__ http://www.informatimago.com/ “The factory of the future will have only two employees, a man and a dog. The man will be there to feed the dog. The dog will be there to keep the man from touching the equipment.” -- Carl Bass CEO Autodesk