From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Robert Thorpe Newsgroups: gmane.emacs.help Subject: Re: plists, alists, and hashtables Date: Wed, 05 Aug 2015 20:40:21 +0100 Message-ID: <871tfhikwq.fsf@robertthorpeconsulting.com> References: <87oailbn8t.fsf@lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1438803665 16120 80.91.229.3 (5 Aug 2015 19:41:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 5 Aug 2015 19:41:05 +0000 (UTC) Cc: help-gnu-emacs@gnu.org To: Ted Zlatanov Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Aug 05 21:40:54 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 1ZN4YX-00089X-Nq for geh-help-gnu-emacs@m.gmane.org; Wed, 05 Aug 2015 21:40:53 +0200 Original-Received: from localhost ([::1]:41880 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZN4YW-0005IY-TW for geh-help-gnu-emacs@m.gmane.org; Wed, 05 Aug 2015 15:40:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58218) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZN4Y9-0005IS-5I for help-gnu-emacs@gnu.org; Wed, 05 Aug 2015 15:40:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZN4Y5-0004ZU-4E for help-gnu-emacs@gnu.org; Wed, 05 Aug 2015 15:40:29 -0400 Original-Received: from outbound-smtp01.blacknight.com ([81.17.249.7]:58254) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZN4Y4-0004ZQ-Ud for help-gnu-emacs@gnu.org; Wed, 05 Aug 2015 15:40:25 -0400 Original-Received: from mail.blacknight.com (pemlinmail01.blacknight.ie [81.17.254.10]) by outbound-smtp01.blacknight.com (Postfix) with ESMTPS id 1421998C36 for ; Wed, 5 Aug 2015 19:40:23 +0000 (UTC) Original-Received: (qmail 10993 invoked from network); 5 Aug 2015 19:40:22 -0000 Original-Received: from unknown (HELO RTLaptop) (rt@robertthorpeconsulting.com@[109.77.177.58]) by 81.17.254.9 with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 5 Aug 2015 19:40:22 -0000 In-Reply-To: <87oailbn8t.fsf@lifelogs.com> (message from Ted Zlatanov on Wed, 05 Aug 2015 14:31:46 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 81.17.249.7 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:106264 Archived-At: Ted Zlatanov writes: > PJB> This extends easily to any other data structure for which you'd want a > PJB> literal representation. > > OK, but still, I'm not interested in heaps, trees, graphs, skip lists, > or other data structures. I'm interested in improving the accessibility > and popularity of hashtables in order to avoid the complexity and > ambiguity of alists and plists when dealing with maps. As Pascal mentioned, we only have a very small number of characters left to use for read syntax. You can't just consider one proposal alone. Just because something is useful doesn't mean that it's useful enough to burn a character or two for. It has to be compared to alternatives. There may be alternatives though. For example, instead of: #s(hash-table size 65 test eql rehash-size 1.5 rehash-threshold 0.8 data ()) We could have a shorthand, perhaps #s(h data) . Like Pascal I think alists are generally a good idea. People who don't understand the performance implications of them won't understand those of hash-maps either. Especially when things are done per key. In an editor the vast majority of maps are likely to contain only a few variables. A few years ago I made a program that examined every Emacs variable that ended in "alist". Almost all of them were short. Only a handful were long enough to cause performance issues. If a hash-map type were used then there could be a bit to signify if it's *really* a hash. I've heard that some of the scripting languages are doing this because they've found what I found; that most maps contain so few elements that hashing just makes things slower. But, the bit would have to be tested before every map operation. BR, Robert Thorpe