Re: hash-table-{to, from}-alist

[Ted Zlatanov <tzz@lifelogs.com>]

On Tue, 02 Dec 2008 18:05:52 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 

SJT> Ted Zlatanov writes:
>> Can you and Stefan figure out whether to have print-readably or
>> not?  I was against it, and Stefan supported that.  But let's see
>> the pro argument and discuss this.

SJT> The pro argument is that unless you're debugging the hash table, it's
SJT> a PITA to have a hash table that gets recursively passed to each
SJT> function down the line taking up 20 screens for each frame in a
SJT> backtrace.  "Not debugging the hash table" is the overwhelmingly
SJT> common occurance for me; usually I'm more interested in where in the
SJT> stack the value I'm going to be puthash'ing turned from gold into
SJT> garbage.  OTOH, about half the time when I've got a chartable in the
SJT> stack, the chartable is buggy (in my experience almost all chartables
SJT> are write-once).

Isn't the same argument valid for lists?  At least in the Emacs
backtrace, lists get shortened for display; I don't know if that's done
at the print level or at the display level.  If it's at the display
level, a lot of cycles are wasted for large lists.

Basically I want to treat hashtables like lists as much as possible for
printing and reading, so print-readably would introduce inconsistency.
Otherwise I agree with your argument, I am just reluctant to make
hashtables an exception to the general print behavior.

>> Will the current state of things cause XEmacs breakage anywhere?

SJT> No.  This is a user interface thing.  If I'm right, XEmacs will get a
SJT> mild popularity boost if you always print the hash table.  I'm not
SJT> going to complain about that! ;-)

Heh.

>> One idea I had is to check if print-readably is bound; if not then
>> we act as if it was bound and t.  That will DTRT in GNU Emacs and
>> in XEmacs, I hope.

SJT> Hm?  XEmacs already has the feature in C; your code will either get
SJT> ignored in XEmacs syncs, or its algorithms will be ported to our C
SJT> code.  Definitely not something for you to worry about.

Great.

Ted