Re: hash tables: print, read, print-readably
Mike Kupfer writes:
Stephen J. Turnbull wrote:
> Mike Kupfer writes:
> XEmacs implementers.
Ah, well that explains a lot of the disconnect here.
Yes. I should also say that I really don't expect to get a lot of
attention from Lisp developers *except* for the occasional person who
wants to port to XEmacs. I don't think they will much care about the
issues you're talking about. I think really the only people who will
care are implementers and curious users.
I think the most important thing at present is for us to encourage the
folks who will provide either new core features, or help porting the
low-level features from GNU.
The Lisp books that I have say very little about what can go inside
#<>,
In Common Lisp, #< signals an error when read. The intended use is
precisely to create a print representation for unreadable objects.
Nothing further is specified. We adopted the same convention. In
XEmacs, each unreadable object has an idiosyncratic representation.
http://www.lispworks.com/documentation/HyperSpec/Body/02_dht.htm
But I really have to question whether this is a wise policy. A
strict
interpretation implies I should ignore the buffer name in
#<buffer "*scratch*">
If I want to know the name of a buffer, I should make a practice of
using #'buffer-name. That seems awkward.
It is. But that's the only way to programmatically access the name of
a buffer. Lisp *is* awkward that way. Including some implementation
details in unreadable print representations that occur as output in
interactive sessions seems to be a clear win to me.
A more lenient interpretation would say I can use the fields that
seem
reliable enough. But figuring out, then keeping track of, which fields
of which types are reliable would be a hassle.
? With very few exceptions, they're quite mnemonic, as in the case of
buffers. Eg, processes:
(process-list) =>
(#<process "ispell" pid 26279 state:run>
#<process "gnuserv" pid 18181 state:run>)
The only complaint I've ever heard is yours about hash tables, but
that is not just XEmacs. Cf.
http://www.lispworks.com/documentation/HyperSpec/Issues/iss190_w.htm
Note also the (unreadable) print representation of hash tables used in
the Hyperspec (the result of `(setq a (make-hash-table))' in
http://www.lispworks.com/documentation/HyperSpec/Body/18_aa.htm).
Doesn't prove anything, but it is a precedent for the format XEmacs
uses.
That said, I can see the writing on the wall. I'm not going to
invest
any additional time lobbying for change in this area.
Lobbying won't help, that's for sure. Patches might, though. I just
don't see any proposals that are clear improvements over the status
quo.
I'd also like to hear about any other unreadable unreadable print
representations you encounter. (Backward/GNU compatibility means we
probably can't do anything about *readable* print representations.)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta