From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: hash-table-{to, from}-alist Date: Sat, 22 Nov 2008 12:57:10 -0600 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: References: <34f9604c-a23b-4ad9-9c84-f45884a6df23@x16g2000prn.googlegroups.com> <86od3dfd86.fsf@lifelogs.com> <868wuflxv9.fsf@lifelogs.com> <863aknitfg.fsf@lifelogs.com> <20080830051807.GB9625@tomas> <86bpwe9su5.fsf@lifelogs.com> <867i6z1jo5.fsf_-_@lifelogs.com> <86ej14vhvg.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1227380266 3895 80.91.229.12 (22 Nov 2008 18:57:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 22 Nov 2008 18:57:46 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 22 19:58:50 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1L3xgu-0008RD-QZ for ged-emacs-devel@m.gmane.org; Sat, 22 Nov 2008 19:58:49 +0100 Original-Received: from localhost ([127.0.0.1]:38902 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L3xfl-0007YB-Kx for ged-emacs-devel@m.gmane.org; Sat, 22 Nov 2008 13:57:37 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L3xfg-0007Y4-Ek for emacs-devel@gnu.org; Sat, 22 Nov 2008 13:57:32 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L3xfd-0007XY-Rc for emacs-devel@gnu.org; Sat, 22 Nov 2008 13:57:32 -0500 Original-Received: from [199.232.76.173] (port=56104 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L3xfd-0007XV-L6 for emacs-devel@gnu.org; Sat, 22 Nov 2008 13:57:29 -0500 Original-Received: from main.gmane.org ([80.91.229.2]:58869 helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1L3xfd-0007js-Ar for emacs-devel@gnu.org; Sat, 22 Nov 2008 13:57:29 -0500 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1L3xfS-0005vz-W4 for emacs-devel@gnu.org; Sat, 22 Nov 2008 18:57:19 +0000 Original-Received: from c-68-60-254-123.hsd1.il.comcast.net ([68.60.254.123]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 22 Nov 2008 18:57:18 +0000 Original-Received: from tzz by c-68-60-254-123.hsd1.il.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 22 Nov 2008 18:57:18 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 57 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-68-60-254-123.hsd1.il.comcast.net 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" User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (darwin) Cancel-Lock: sha1:on9CdCIR2zV4vMcOM8hzGaCUltc= X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:105968 Archived-At: On Fri, 21 Nov 2008 22:18:41 -0500 Stefan Monnier wrote: Ted Zlatanov wrote: >> { :prop1 prop-value1 :prop2 prop-value2 ... key1 val1 key2 val2 ... } >> (:prop1 is :test for example) SM> I was thinking of something more like # where "..." SM> would contain the props and then the key/value pairs. I.e. an extension SM> of the current (un`read'able syntax). Why would you want to make it unreadable if (as above, and in the other proposals) you can make it readable? The whole point of this discussion was serializing hash tables; pretty-printing them is trivial. On Sat, 22 Nov 2008 21:27:18 +0900 "Stephen J. Turnbull" wrote: SJT> I'm not sure what's wrong with SJT> (let ((tbl (make-hash-table ...))) SJT> (puthash key1 val1 tbl) SJT> ...) SJT> as a read syntax for hash tables. It's verbose, and doesn't follow what vectors do (they use [] instead of (make-vector ...), setting some precedent for special read syntax). OTOH it's readable, extensible, and easy to set up your way. SJT> N.B. XEmacs and SXEmacs already have lots of object types. If you're SJT> going to start proliferating `read'able print syntaxes, starting with SJT> an extensible one would be nice. I only want some format that lets me easily print and read back a hash table; the actual syntax is not important to me. My proposal was only a suggestion. On Sun, 23 Nov 2008 02:38:59 +0900 "Stephen J. Turnbull" wrote: SJT> BTW, it turns out that in XEmacs and its descendants prin1 uses the CL SJT> structure syntax when `print-readably' is bound to t: SJT> #s(hash-table size 1 data (x x-value)) SJT> This is not guaranteed to actually be acceptable to the reader, since SJT> some contained objects may not be printable (eg, improper lists). SJT> However, since most types in XEmacs do have readable print SJT> representations, it does correctly recurse on composite types like SJT> hash tables (as long as the expression is a tree; DAGs will contain SJT> copies, cycles will be elided, etc). That's fine too, and it would make sense to use something that has been proven to work already. As I said, the syntax doesn't matter to me. Whatever the Emacs maintainers and developers like is OK, it just has to work :) Ted