Re: hash tables: print, read, print-readably
Ar an triochadú lá de mí Bealtaine, scríobh Raymond Toy:
>>>>> "Mike" == Mike Kupfer
<mike.kupfer(a)xemacs.org> writes:
Mike> [...] To get the right syntax you have to bind print-readably
Mike> to t, as in
Mike> (let ((print-readably t)) (prin1-to-string myhash))
Mike> => "#s(hash-table :size 1 :data (\"a\"
\"foo\"))"
Mike> (read-from-string (let ((print-readably t)) (prin1-to-string
Mike> myhash)))
Mike> => (#<hash-table :size 1/29 :data ("a" "foo")
0x636>
Mike> . 40)
Does it really make sense to print out hash tables like this? I'm not
very familiar with xemacs hashtables, but what happens if you do
something like
(defvar obj "abc")
(puthash 1 obj myhash)
(puthash 2 obj myhash)
Then the value for both keys 1 and 2 are eq. If you read the printed
representation back in, won't the value for the two keys no longer be
eq?
It won’t, you are correct. This is a long-standing oddity (and, really, a
bug, but so long-standing and intrinsic that I’m not going to make it a
priority right now) in the way the Emacs Lisp reader and printer treats
strings.
XEmacs already handles the analogous case for other eq-identical objects,
e.g:
(progn
(defvar obj '(a b c))
(puthash 1 obj myhash)
(puthash 2 obj myhash)
(setq print-readably t
print-circle t))
=> t
myhash
=> #s(hash-table :size 2 :data (1 #1=(a b c) 2 #1#))
We could easily do it for strings too, just by adding a print_preprocess
method to the string object, but this is half-defeated by this, in
bytecomp.el:
(defmacro byte-compile-get-constant (const)
`(or (if (stringp ,const)
(assoc ,const byte-compile-constants)
(assq ,const byte-compile-constants))
(car (setq byte-compile-constants
(cons (list ,const) byte-compile-constants)))))
This means that different-under-eq constants that are not strings remain
different in bytecode, but strings are differentiated using equal.
Or can xemacs print objects like common-lisp using things like #1#
to make sure they're the same object?
--
‘Liston operated so fast that he once accidentally amputated an assistant’s
fingers along with a patient’s leg, […] The patient and the assistant both
died of sepsis, and a spectator reportedly died of shock, resulting in the
only known procedure with a 300% mortality.’ (Atul Gawande, NEJM, 2012)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta