Re: hash-table-{to, from}-alist

[Ted Zlatanov]

On Fri, 21 Nov 2008 22:18:41 -0500 Stefan Monnier <address@hidden> 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 #<hash-table ...> 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" <address@hidden> 
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" <address@hidden> 
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