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: Thu, 06 Aug 2015 20:46:09 +0200 Organization: Informatimago Message-ID: <8737zwntla.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> 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 1438895491 21297 80.91.229.3 (6 Aug 2015 21:11:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Aug 2015 21:11: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:11:27 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 1ZNSRh-0000iK-1c for geh-help-gnu-emacs@m.gmane.org; Thu, 06 Aug 2015 23:11:25 +0200 Original-Received: from localhost ([::1]:46224 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNQFH-0003VX-4I for geh-help-gnu-emacs@m.gmane.org; Thu, 06 Aug 2015 14:50:27 -0400 Original-Path: usenet.stanford.edu!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 109 Original-X-Trace: individual.net eBakbO2icoihUZGkML1QFgzBcqdEYCXgNCEu2baV2/ArIBPFfZ Cancel-Lock: sha1:Y2Y4ODViNmI1NzcyMDllNTU3NDM5MTc4MDZlNjAyNmEyNmFiMDcxMA== sha1:Etr6auGHdlfk3OOk22IPVgK/W6o= 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:214010 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:106301 Archived-At: 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. Why? The whole point of lisp, is to recognize that things don't need to look different at all, that you get much more mileage by using a uniform syntax for everything: (operator argument argument…) Or in the case of plain data: (type attribute attribute). which is the same in the case of (BOA) constructors: (vector 1 2 3) (list 'thx 1138) (point 10.3 12.4 'red) I've been advocating for readtable and reader macros as a mean for _end_ _user_ extension, not because I support adding syntaxes to lisp. Additionnal syntaxes can be useful, and should only be used, for end users and DSL implementing a domain with pre-existing _extensive_ use of that syntax. For example, if you were programming a physics simulation, with a lot of differential mathematical equations that you'd copy from books, you might implement a DSL for infix mathematical expressions with all kinds of reader macro to be able to transcribe the printed formular as closely as possible (just to avoid bugs in the transcription, that will be performed by your DSL reader macros and macros). But even in this case, for new code, you would be strongly advised to use lisp sexps, cf. sicm. http://mitpress.mit.edu/sites/default/files/titles/content/sicm/book.html https://www.youtube.com/watch?v=arMH5GjBwUQ Notice that if you quote an expression using strange reader macros, you will see what lisp expression it actually represent, and you can use that instead. For example, I have a reader macro that lets me write Objective-C FFI calls in Common Lisp: [NSDictionary dictionary] --> # If I wanted to avoid this reader macro, I could quote it, to see what it reads as: '[NSDictionary dictionary] --> (objc:send ns:ns-dictionary 'dictionary) (objc:send ns:ns-dictionary 'dictionary) --> # (in this case, I usually don't want to get out of the DSL, since it implies a strong dependency on Objective-C frameworks, I just restrict the use of the #\[ reader macro to low level system modules, not spreading them all around the program). But maps are not something out of this lisp world. They existed from the start as a-list, then p-list and then hash-tables. They are a basic data structure perfectly integrated to an algorithmic programming language, and don't constitute a different, Domain Specific Language. For this reason, they should use the usual lisp sexps. Also: « Ceci est une chaîne de caractères ! » » Dies ist ein String « Therefore « and » are very confusing characters to choose for maps. If you want some "syntax", could instead use → (but again, it's also a heavily overloaded character). →(k1 v1 k2 v2 k3 v3) which would read as: '→(k1 v1 k2 v2 k3 v3) --> #s(hash-table size 65 test eql rehash-size 1.5 rehash-threshold 0.8 data (k1 v1 k2 v2 k3 v3)) Then you could define a printer for hash-tables to print them as →(k1 v1 k2 v2 k3 v3) Then you will have to patch all the editors in the world (not only emacs, people also use vim, textmate, eclipse, notepad, etc to edit lisp), to teach them about this → that is not inside the parentheses… -- __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