10:47 p.m.
There was a recent discussion on ding(a)gnus.org about problems that
recent versions of Gnus have with XEmacs. One of the issues was stated
as XEmacs not having a "printed representation for hash tables". It
turns out that that's not strictly true, but I can see where someone
might think it's true.
The main issue is that the default format for printing a hash table
cannot be read back in.
(setq myhash (makehash))
=> #<hash-table :size 0/29 0x5ef>
(puthash "a" "foo" myhash)
=> "foo"
(prin1-to-string myhash)
=> "#<hash-table :size 1/29 :data (\"a\" \"foo\")
0x5ef>"
(read-from-string (prin1-to-string myhash))
=> Invalid read syntax: cannot read unreadable object.
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\"))"
(read-from-string (let ((print-readably t)) (prin1-to-string myhash)))
=> (#<hash-table :size 1/29 :data ("a" "foo") 0x636> . 40)
This seems awkward. Can we change the default format for printing hash
tables, or would that require a major version bump?
If we're stuck with print-readably for the foreseeable future, it seems
like the docstring for print et al should mention it.
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...?
mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
12:44 a.m.
>>>> "Mike" == Mike Kupfer
<mike.kupfer(a)xemacs.org> writes:
Mike> There was a recent discussion on ding(a)gnus.org about problems that
Mike> recent versions of Gnus have with XEmacs. One of the issues was stated
Mike> as XEmacs not having a "printed representation for hash tables".
It
Mike> turns out that that's not strictly true, but I can see where someone
Mike> might think it's true.
Mike> The main issue is that the default format for printing a hash table
Mike> cannot be read back in.
Mike> (setq myhash (makehash))
Mike> => #<hash-table :size 0/29 0x5ef>
Mike> (puthash "a" "foo" myhash)
Mike> => "foo"
Mike> (prin1-to-string myhash)
Mike> => "#<hash-table :size 1/29 :data (\"a\"
\"foo\") 0x5ef>"
Mike> (read-from-string (prin1-to-string myhash))
Mike> => Invalid read syntax: cannot read unreadable object.
Mike> To get the right syntax you have to bind print-readably 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 myhash)))
Mike> => (#<hash-table :size 1/29 :data ("a" "foo")
0x636> . 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?
Or can xemacs print objects like common-lisp using things like #1#
to make sure they're the same object?
Ray
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:12 a.m.
Raymond Toy wrote:
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?
Yes, that appears to be the case, both for XEmacs and Emacs 23.
(setq newhash (car (read-from-string
(let ((print-readably t)) (prin1-to-string myhash)))))
=> #<hash-table :size 2/29 :data (1 "abc" 2 "abc") 0x1989>
(eq (gethash 1 myhash)
(gethash 2 myhash))
=> t
(eq (gethash 1 newhash)
(gethash 2 newhash))
=> nil
I agree that that's unfortunate. But apparently Gnus doesn't need this
additional level of correctness in the external representation.
mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
8:28 a.m.
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
1:17 p.m.
Mike Kupfer writes:
> 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?
Yes, that appears to be the case, both for XEmacs and Emacs 23.
That's interesting. I'm pretty sure we do the right thing for
printing circular lists and so on, so it should be possible to do it
for hashtables without too much effort.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:36 p.m.
Stephen J. Turnbull wrote:
Mike Kupfer writes:
> > 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?
>
> Yes, that appears to be the case, both for XEmacs and Emacs 23.
That's interesting. I'm pretty sure we do the right thing for
printing circular lists and so on, so it should be possible to do it
for hashtables without too much effort.
Okay, I'll open an issue in the tracker.
thanks,
mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
6:33 p.m.
Stephen J. Turnbull wrote:
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.
And probably more portable. Maybe I'll suggest that to the Gnus folks.
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.
Hmm. Okay, I missed the fact that the string generated by XEmacs had 1,
and my made-up example (which was older and came from reviewing the
documentation) had 29.
But I still find this confusing. I would expect--both based on your
description and the documentation--that
#s(hash-table :size 29 :data ("a" "foo"))
would give me a table sized to hold 29 elements, but currently only
holding 1 element.
Really, the size of a hash table is none-of-your-business-thank-you-
very-much. ;-)
Perhaps, except I was afraid that every round-trip would result in a
larger hash table. That would eventually become my business. ;-)
And if it's not my business, then XEmacs probably shouldn't expose it in
the default printed representation.
mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
8:08 p.m.
Mike Kupfer writes:
But I still find this confusing. I would expect--both based on your
description and the documentation--that
#s(hash-table :size 29 :data ("a" "foo"))
would give me a table sized to hold 29 elements, but currently only
holding 1 element.
An XEmacs hash table sized to hold 29 actual elements has 59 buckets.
Hash tables need empty buckets to work efficiently.
> Really, the size of a hash table is
none-of-your-business-thank-you-
> very-much. ;-)
Perhaps, except I was afraid that every round-trip would result in a
larger hash table. That would eventually become my business. ;-)
It will do so if you keep fiddling the :size parameter by hand. If
you leave that alone, you'll have no problem. In fact, if the number
of actual elements shrinks enough, next time XEmacs will allocate a
smaller number of buckets.
And if it's not my business, then XEmacs probably shouldn't
expose it in
the default printed representation.
In the *default* printed representation, it's no problem. That
representation is un(read)able. ;-) In the (read)able printed
representation, it mimics the API of make-hash-table, except for the
:data key, which is basically a plist. (Currently, apparently it is
*exactly* a plist.) That seems like an excellent and self-documenting
API to me, at least for anybody who knows the make-hash-table API
already.
True, I suppose it could be abused by a merry prankster who writes
#s(hash-table :size 2147483647 :data ("a" "foo"))
or similar. But I don't recommend using this API at all, so I'm not
going to worry about it.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:05 p.m.
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
6:03 p.m.
Stephen J. Turnbull wrote:
Mike Kupfer writes:
> > Really, the size of a hash table is
none-of-your-business-thank-you-
> > very-much. ;-)
[...]
> And if it's not my business, then XEmacs probably
shouldn't expose it in
> the default printed representation.
In the *default* printed representation, it's no problem. That
representation is un(read)able. ;-)
It may not be a problem for someone who's familiar with the
idiosyncrasies of XEmacs Lisp, but this was my first exposure to Lisp
hash tables, and I found it confusing.
mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4 a.m.
Mike Kupfer writes:
It may not be a problem for someone who's familiar with the
idiosyncrasies of XEmacs Lisp, but this was my first exposure to Lisp
hash tables, and I found it confusing.
The only answer I have to that is RTFM. :-( Hash tables are simple in
concept, and complex in implementation. AFAICT efficiency requires
exposing a bit of the complexity (the :size parameter) to the user.
The printed representation you seem to want is a plain plist[1] (which I
agree with, of course -- that's what I suggested, too). However, all
of the pieces of the current representation are useful.
If you have a bone to pick with TFM, let me know and I'll fix it (and
"patches welcome", of course).
Footnotes:
[1] Plus some syntactic sugar to tell the Lisp reader this is a hash
table.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:28 p.m.
Stephen J. Turnbull wrote:
The only answer I have to that is RTFM. :-( Hash tables are simple
in
concept, and complex in implementation. AFAICT efficiency requires
exposing a bit of the complexity (the :size parameter) to the user.
Part of problem is that the default print representation prints the
number of buckets, rather than the maximum number of elements. So it's
punching a hole in the hash table abstraction and exposing an
implementation detail. If someone really needs to know the number of
buckets, let's provide a API for that.
To make matters worse, the printed representation uses the same "size"
keyword. So "size" means one thing in the default printed
representation, but it means something else in the readable
representation and in the API. I think this inconsistency is the main
thing I find annoying.
These are code issues, which I think should be fixed (modulo the usual
caveats about when someone finds time to do it).
If you have a bone to pick with TFM, let me know and I'll fix it
(and
"patches welcome", of course).
The docstring for print and friends should mention print-readably. A
specific list of objects for which print-readably is relevant (e.g.,
hash table) would be nice, but I can see arguments for not including
such a list.
I may have some suggestions for make-hash-table, too, but I want to
think about that a little more.
I can put some doc patches on my to-do list if we have rough agreement
about what should go into them.
mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
6:49 p.m.
Mike Kupfer writes:
So it's punching a hole in the hash table abstraction and
exposing
an implementation detail.
So what? It prints an object ID, too, which is also internal. The
usage ratio is a useful number to know in some cases (it has a bearing
on the performance of hash tables) and easy enough to print.
To make matters worse, the printed representation uses the same
"size"
keyword. So "size" means one thing in the default printed
representation, but it means something else in the readable
representation and in the API.
It actually means different things in the readable representation and
in `make-hash-table' it seems to me. In the readable representation,
it's the current number of items, while in the API it's the expected
long-run number. Thus
(let ((print-readably t)
(foo (make-hash-table :size 100)))
(puthash 1 1 foo)
(prin1 foo))
#s(hash-table:size 1 :data (1 1))
#<hash-table:size 1/197 :data (1 1) 0x20a1d>
But if you find a better word for the size in the unreadable
representation, we can use it there. I don't much like either of
"usage" or "ratio", and "usage ratio" is too long. It
should be
short, too, no more than about 5-6 characters.
The docstring for print and friends should mention print-readably.
A
specific list of objects for which print-readably is relevant (e.g.,
hash table) would be nice, but I can see arguments for not including
such a list.
The docstring for print-readably already has such a list, but it's
only two types long, specifically missing hash tables. I think that
is where it belongs.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:32 a.m.
Stephen J. Turnbull wrote:
Mike Kupfer writes:
> So it's punching a hole in the hash table abstraction and exposing
> an implementation detail.
So what? It prints an object ID, too, which is also internal. The
usage ratio is a useful number to know in some cases (it has a bearing
on the performance of hash tables) and easy enough to print.
Well, we could have a discussion about when internal information should
be displayed, but for now I'd be happy if we change the keyword.
> To make matters worse, the printed representation uses the same
"size"
> keyword. So "size" means one thing in the default printed
> representation, but it means something else in the readable
> representation and in the API.
It actually means different things in the readable representation and
in `make-hash-table' it seems to me. In the readable representation,
it's the current number of items, while in the API it's the expected
long-run number.
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. ;-)
The thing is, for make-hash-table and the readable representation, the
number refers to objects, not buckets.
But if you find a better word for the size in the unreadable
representation, we can use it there. I don't much like either of
"usage" or "ratio", and "usage ratio" is too long. It
should be
short, too, no more than about 5-6 characters.
I was thinking either "buckets" or "slots". Would either of those
work
for you? I lean towards "buckets", as "hash bucket" is, I think, a
well-known idiom, but either would do.
> The docstring for print and friends should mention
print-readably. A
> specific list of objects for which print-readably is relevant (e.g.,
> hash table) would be nice, but I can see arguments for not including
> such a list.
The docstring for print-readably already has such a list, but it's
only two types long, specifically missing hash tables. I think that
is where it belongs.
Okay.
mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:26 a.m.
Mike Kupfer writes:
Well, we could have a discussion about when internal information
should be displayed,
We could, but I'd be strongly in favor of the status quo: objects with
an unreadable print representationshould have a representation that
displays any information that developers find useful.
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.
The thing is, for make-hash-table and the readable representation,
the
number refers to objects, not buckets.
Sure. All representations refer to objects. The unreadable
I was thinking either "buckets" or "slots".
I don't like either, because the more interesting number is usually
the number of objects, not the number of buckets. I would rather use
:size, or maybe :sizes, because that's the semantics of those
numbers. The latter might be interesting if we ever decide to keep
the initialization size around, then the unreadable format might be
:sizes used/estimated/buckets
and for printable the semantics would be
:size max{used,estimated}
(This could cause an upward drift in the requested sizes, but only if
you actually needed it).
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:08 a.m.
Stephen J. Turnbull writes:
> The thing is, for make-hash-table and the readable
representation, the
> number refers to objects, not buckets.
Sure. All representations refer to objects. The unreadable
I meant to continue, "representation also contains the number of
buckets."
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:04 p.m.
Stephen J. Turnbull wrote:
Mike Kupfer writes:
> Well, we could have a discussion about when internal information
> should be displayed,
We could, but I'd be strongly in favor of the status quo: objects with
an unreadable print representationshould 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?
> 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 thing is, for make-hash-table and the readable
representation, the
> number refers to objects, not buckets.
Sure. All representations refer to objects. The unreadable
representation also contains the number of buckets.
Which is presented in a way that makes it look like it's the expected
long-term number of objects.
This is not documented anywhere that I have seen. If I'm a Lisp newbie
and I'm futzing around in *scratch*, trying to understand something
about hash tables, and the interpreter tells me that my experimental
hash table is
#<hash-table :size 2/29 0x719>
then it seems reasonable to conclude that the 29 refers to objects. It
uses the same "size" keyword that is documented for #'make-hash-table,
and the 2 is clearly the number of actual objects in the table.
So if the 2/29 is for consumption by Lisp application writers, it's
misleading and confusing. 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.
Could the 2/29 be broken up, e.g.,
:size 2 :buckets 29
?
mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:54 a.m.
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
5:45 a.m.
Stephen J. Turnbull wrote:
Mike Kupfer writes:
> Stephen J. Turnbull wrote:
> By "developers", do you mean XEmacs implementors, or do you mean people
> trying to write Lisp applications?
XEmacs implementers.
Ah, well that explains a lot of the disconnect here.
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.
The Lisp books that I have say very little about what can go inside #<>,
which suggests to me that this is an XEmacs policy, rather than some
well-known aspect of Lisp. If that's true, then the policy should be
documented in the docstring of #'print and friends.
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. And talk about attractive
nuisances...
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.
Either way, the application programmer loses.
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.
mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:23 p.m.
> "Mike" == Mike Kupfer <mike.kupfer(a)xemacs.org>
writes:
Either way, the application programmer loses.
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.
Let me see whether I understand the background of the problem. Gnus has,
since approximately 2 years, the feature of adding registers (tag) to its
messages, a feature for example Thunderbirds provides.
It was not very stable and maybe that is why Ted changed the
implementation entirely, using in some way hash tables, but the
consequence was/is that this nifty feature cannot be used any more in
Xemacs.
If I understand it correctly Steve is against such a feature because it
might cause problems in other places (and should so in GNU Emacs). Is
this correct?
If so, I assist Mike: at the end GNU Emacs has a nifty feature and
Xemacs has none.
Uwe Brauer
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
6:02 p.m.
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
6:36 p.m.
Uwe Brauer writes:
It was not very stable and maybe that is why Ted changed the
implementation entirely, using in some way hash tables, but the
consequence was/is that this nifty feature cannot be used any more in
Xemacs.
It can be used. Just bind the variable `print-readably' before
printing the hash-table.
It looks like `print-readably' is a no-op to Emacs, so you don't even
need a separate implementation (but the byte compiler will complain).
But there's a better way to do persistent hashes in XEmacs. See
`open-database'.
If I understand it correctly Steve is against such a feature
because it might cause problems in other places (and should so in
GNU Emacs). Is this correct?
No. The discussion I was having with Mike is not about how to print
hash-tables readably; he already knew how to do that when he posted.
It's about whether we should change the format of the unreadable
representation.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
8:19 p.m.
Stephen J. Turnbull wrote:
Mike Kupfer writes:
> 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.
But then I still have to remember which ones are the exceptions. And
someone who's coming in cold might not even realize that there *are*
exceptions.
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.
I don't mind it being unreadable, I just mind the misleading "size"
keyword.
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.
The only other proposal I can think of would be to drop the "size"
keyword entirely.
Putting together a patch would take time away from other things, like
updating the MH-E package. I'm not even going to consider it without
some agreement over what the patch should do. (And that's more what I
meant by lobbying. I'm not trying to badger someone else into
implementing the change.)
mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:34 a.m.
Mike Kupfer writes:
I don't mind it being unreadable, I just mind the misleading
"size"
keyword.
It's not misleading, it's ambiguous. I suspect the main reason you
think anything else would be better is because you were bit by this
one, and won't make the mistake with any other keyword because of
that. But the alternatives are just as ambiguous or non-descriptive:
The only other proposal I can think of would be to drop the
"size"
keyword entirely.
Make it more cryptic as a warning to the naive? That might work.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:03 a.m.
Stephen J. Turnbull wrote:
Mike Kupfer writes:
> The only other proposal I can think of would be to drop the "size"
> keyword entirely.
Make it more cryptic as a warning to the naive? That might work.
Please think about it (at your leisure). I would find an up-or-down
response on the concept helpful.
thanks,
mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3973
days inactive
3983
days old
24 comments
5 participants
participants (5)
-
Aidan Kehoe -
Mike Kupfer -
Raymond Toy -
Stephen J. Turnbull -
Uwe Brauer