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: Wed, 05 Aug 2015 16:08:48 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87k2t9bir3.fsf@lifelogs.com> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1438805425 11962 80.91.229.3 (5 Aug 2015 20:10:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 5 Aug 2015 20:10:25 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Aug 05 22:10:25 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 1ZN513-0004Ve-FV for geh-help-gnu-emacs@m.gmane.org; Wed, 05 Aug 2015 22:10:21 +0200 Original-Received: from localhost ([::1]:41944 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZN512-000251-Gh for geh-help-gnu-emacs@m.gmane.org; Wed, 05 Aug 2015 16:10:20 -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: 50 Original-X-Trace: news.albasani.net NHlUv+7iarrTmn+SSHlRg5xbrwXMmnElCN/JY0bd4E1bdGXG0GRS61EAyUJkPUNftfWQdoJM553zTA3NoIebrA== Original-NNTP-Posting-Date: Wed, 5 Aug 2015 20:08:48 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="WqadXEi5YSoVjKNvVLYvsWHE39eWWYShX3RWtbRDB/7JaxzNoX9o0e22OCrTST0VeDUmGMNxe22J7gYIdFImIq/bMLiI4Q+Mw6h/LoWASU3u1ZsvTPTXrDf5kH64fFkl"; 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:MQD699Xjb7fqVBT2I8CMqBoVkwA= sha1:sLhdJhSRzSEZ7OI0FanI5TuYgJE= Original-Xref: usenet.stanford.edu gnu.emacs.help:213981 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:106266 Archived-At: On Wed, 05 Aug 2015 20:40:21 +0100 Robert Thorpe wrote: RT> As Pascal mentioned, we only have a very small number of characters left RT> to use for read syntax. RT> You can't just consider one proposal alone. Just because something is RT> useful doesn't mean that it's useful enough to burn a character or two RT> for. It has to be compared to alternatives. OK, I understand your viewpoint. My goal is not to burn characters but to make it easy to create a map in ELisp. RT> There may be alternatives though. For example, instead of: RT> #s(hash-table size 65 test eql rehash-size 1.5 rehash-threshold 0.8 data ()) RT> We could have a shorthand, perhaps #s(h data) That's all right, but I would probably prefer a Unicode pair of characters. In 2015, that's going to inconvenience very few people. RT> Like Pascal I think alists are generally a good idea. People who don't RT> understand the performance implications of them won't understand those RT> of hash-maps either. Especially when things are done per key. RT> In an editor the vast majority of maps are likely to contain only a few RT> variables. A few years ago I made a program that examined every Emacs RT> variable that ended in "alist". Almost all of them were short. Only a RT> handful were long enough to cause performance issues. I see what you mean. The benefit to the users who use a hypothetical new map syntax would be mostly code readability, because alists and plists are not as readable as a true map syntax. Is that enough to justify it? If it's not obtrusive and doesn't burn reader characters, I think so. 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? RT> If a hash-map type were used then there could be a bit to signify if RT> it's *really* a hash. I've heard that some of the scripting languages RT> are doing this because they've found what I found; that most maps RT> contain so few elements that hashing just makes things slower. But, the RT> bit would have to be tested before every map operation. I think the bit check performance penalty would be insignificant, and that the backend implementation can adapt to use lists for small maps. In any case, using these would be voluntary, people can still use the usual alists and plists. Ted