hash tables: print, read, print-readably
Mike Kupfer writes:
The main issue is that the default format for printing a hash table
cannot be read back in.
That's by design. I don't really understand why anybody wants a
read-able format for hash tables. alists or plists are much prettier.
(setq table nil)
(maphash (lambda (k v) (push (cons k v) table) (read))
(setq hash-table (make-hash-table))
(mapc (lambda (x) (puthash (car x) (cdr x) hash-table)) table)
(For a plist, use `(push k (push v table) table)'. The corresponding
change to the reader is left as an exercise.)
To get the right syntax you have to bind print-readably to t, as in
(let ((print-readably t)) (prin1-to-string myhash))
=> "#s(hash-table :size 1 :data (\"a\" \"foo\"))"
Doesn't that make you want to gag?
Also, while I was playing around with this on 21.5.33, I noticed the
following oddity. Suppose I put the following text into a buffer:
#s(hash-table :size 29 :data ("a" "foo"))
If I then put point at the "#" and type
M-: (read (current-buffer))
I get a hash table back, and it has the right contents, but it's size
59, not 29. That's a bug, I guess...?
Not that I can see. In the #s format, :size corresponds to the :size
hint to make-hash-table, ie, the expected long-run maximum number of
elements. (That's why the representation printed has a "1" there in
your example.) A 29/29 hash table gives poor performance, so XEmacs
bumps the table to the next size.
Really, the size of a hash table is none-of-your-business-thank-you-
very-much. ;-) That kind of thing is an important reason why hash
tables shouldn't have a read-able representation.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta