Re: hash tables: print, read, print-readably
Mike Kupfer writes:
Stephen J. Turnbull wrote:
> I'd be strongly in favor of the status quo: objects with an
> unreadable print representation should have a representation that
> displays any information that developers find useful.
By "developers", do you mean XEmacs implementors, or do you mean people
trying to write Lisp applications?
XEmacs implementers.
> > Yeah, I thought it a little odd when I first noticed that.
But I
> > convinced myself that for a literal constant, the current number of
> > items is the same as the expected long-run number. ;-)
>
> Not if you interrupt the process immediately after initialization, and
> it decides to dump an empty table to reread later.
Sorry, I'm not following you here.
The table is empty, but you may have told XEmacs that you expect 10000
items. Although XEmacs currently uses "0" for :size in this case, in
principle it could use "10000".
[Number of buckets] is presented in a way that makes it look like
it's the expected long-term number of objects.
YMMV. I've never thought of it that way, always as buckets, even
though I don't recall ever actually looking at the implementation.
So if the 2/29 is for consumption by Lisp application writers,
it's
misleading and confusing.
It's not. Hash tables are an opaque type.
In general, anything you see inside "#<>" or "#s()" should be
considered to be private data for the use of Those Who Know[tm] and
the implementation. If you're not in that subset, but want to be,
read the source, or (with luck) the Internals manual. IOW, it's
exposed for use by the implementers, and to encourage the curious
(curiosity is very welcome :-).
Those writing applications should be concerned with the API as
presented in the XEmacs Lisp manual and docstrings. They can report a
bug/RFE if either the API or the doc is insufficient, or if the need
is great they can resort to reading the source and even monkeypatching.
The print representations (unreadable and readable) are not part of the
public API. I understand the impulse that Emacs Lisp ought to provide
a serialized representation of hash tables that can be read back in.
But I don't see a good reason why an application writer should be able
to conveniently write that serialized representation by hand.
It may not be part of the formal API, but it still contributes to
an ecosystem that's more difficult to work in, and more
intimidating to non-experts, than it needs to be.
I suppose so, except there's a simple, generic rule, as described
above. Simply: "No user-servicable parts." Think of it as one of
those model cars with a clear plastic body so you can see the
internals, but not touch them.
Could the 2/29 be broken up, e.g.,
:size 2 :buckets 29
It could, but what's the point? The information is directly useful
only to XEmacs implementers. Application writers should ignore it in
favor of the public API. In fact, that looks like an attractive
nuisance to me: I can easily see users attempting to specify :buckets
in their calls to make-hash-table. And :size in the representation
has different semantics from :size in the constructor. You just can't
win.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta