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 11:17:48 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87si7wtpib.fsf@lifelogs.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> 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 1438874429 30559 80.91.229.3 (6 Aug 2015 15:20:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Aug 2015 15:20:29 +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 17:20:26 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 1ZNMy1-000379-D0 for geh-help-gnu-emacs@m.gmane.org; Thu, 06 Aug 2015 17:20:25 +0200 Original-Received: from localhost ([::1]:45535 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNMy0-0001SV-F8 for geh-help-gnu-emacs@m.gmane.org; Thu, 06 Aug 2015 11:20:24 -0400 Original-Path: usenet.stanford.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!bcyclone05.am1.xlned.com!bcyclone05.am1.xlned.com!feeder.erje.net!1.eu.feeder.erje.net!news.albasani.net!.POSTED!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 108 Original-X-Trace: news.albasani.net JyZvYHyJ7No0/JKAtwyOdj8v2wkytiTzydJEQW+U+KsHdOPJAe5ZkCuwk+WiFds1Che1zfxurPjumzrEIIKk8A== Original-NNTP-Posting-Date: Thu, 6 Aug 2015 15:17:48 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="iY+iAUEKjrHbr32CBnCZ0b2X2nu4A0n8/FvZZ6Da6urV0Z2rMUPNPgHbdZSeyXOe9T9xOQ1bGpD1jEMEOlXCntFwUm7Hw1bueTI4ACQorKpoYFmAqLED60IigAr04wLP"; 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:gpYhobsDWM1rtCYsBPloTMM6aMc= sha1:Vabf/N9lYaed1s23fr82U2OMeB0= X-Received-Bytes: 6589 X-Received-Body-CRC: 1935344626 Original-Xref: usenet.stanford.edu gnu.emacs.help:214009 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:106293 Archived-At: On Wed, 05 Aug 2015 23:11:41 +0200 "Pascal J. Bourguignon" wrote: PJB> Ted Zlatanov writes: >> I think these details are easily optimized at the C level. Clearly an >> alist is better as the *backend* hashtable implementation for up to 10, >> possibly up to 100 entries (depending on caching, pipelining, hashing >> function, and other factors). But the frontend presentation is what I'm >> concerned about. PJB> So you're not discussing about hash-tables, but about how to provide PJB> high level abstractions. Well DUH, just program them! functions, PJB> macros. I was trying to say the best way today to provide the map abstraction seems to be to use hashtables and to improve them for small sizes on the backend, rather than try to hack around them. PJB> And yes, if you had readtables and reader macros, also a reader macro. PJB> Don't ask for a dictionary abtraction. Ask for readtables and reader PJB> macros! So that you may implement your own syntax for your own PJB> abstractions! Sure, though I wasn't asking for either of those, I was wondering if they would become popular enough that people would migrate to them. The actual implementation may require reader macros and other tools, which will happen on emacs-devel I assume. PJB> Yes, you're asking about an abstraction and a nice API and syntax for PJB> it. PJB> I'm saying ok, implement it, lisp is good for that. (It could be better PJB> with reader macros). Cool, thanks for agreeing on this. I think it would be nice too. I'll bring it up on emacs-devel next. PJB> I'm also saying, beware anyways, because even with adaptative data PJB> structures abstracted away, you will aways have some (usage) complexity PJB> coming up, from the fact that your abstract operations will have some PJB> overhead and some time and space complexity that may not be what is the PJB> best in some specific cases. Of course, but that's something we (maybe) learn in basic data structures courses. On Wed, 05 Aug 2015 23:41:03 +0200 "Pascal J. Bourguignon" wrote: PJB> Ted Zlatanov writes: >> That's all right, but I would probably prefer a Unicode pair of >> characters. In 2015, that's going to inconvenience very few people. PJB> Not on GUI, but people using emacs in (virtual) terminals are still PJB> numerous, and there support for unicode, notably fancy characters, is PJB> much more limited. PJB> Therefore I would advise to implement a unicode syntax only as an PJB> additionnal alternative, not as the main one. Good point, though I think « and » specifically, being very widely used, will be all right. >> So as a first cut, maybe «(k1 . v1) (k2 . v2)» and ««(k1 . v1) (k2 . >> v2)»» would be a good syntax (equal and eql versions respectively), >> simply converted to the appropriate #s(hash-table ...) syntax? PJB> I would drop the dot. And I fail to see a reason to keep the PJB> parentheses too. Visually, you'd end up with a mess then. This has to be readable in the source code, not just to a machine. PJB> When you write the lisp form: (hash-table-eql k1 v1 k2 v2 k3 v3) PJB> you've actually written a list, PJB> but there is a function named hash-table-eql PJB> that turns it into a hash-table. PJB> Now, you could also write: (k1 v1 k2 v2 k3 v3) PJB> and have that be turned into a hash-table, PJB> because you would have written it in the context of a DSL or macro, PJB> that would have proven or assumed it is hash-table data. PJB> In both cases, the sexp notation with no supplementary syntaxes is PJB> enough to denote your high level data structures. 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> If you want to cater to the need of the future programmers, perhaps it PJB> would be better to go toward making lisp a more high level programming PJB> language, not adding syntax and specific distinct data structures, but PJB> by having a smarter "eval" engine that is able to prove things about the PJB> denoted data and programs, and to translate it into the most adapted PJB> data structures and algorithms. ... PJB> Similarly, instead of dicussing about #S(hash-table) vs «» vs PJB> #.(hash-table …), it would be better to think about implementing theorem PJB> prover features into a lisp to make it a higher level programming PJB> language, so you don't have to care about what exact low level data PJB> structure or algorithm is used, as long as the system has been able to PJB> prove nice features of your high level description, which can be already PJB> written with plain sexps. I'll put that on my TODO list, sure :) Ted