Re: [MIT-Scheme-devel] make-eq-hash-table

[Taylor R Campbell]

   Date: Sun, 20 Dec 2009 13:48:59 -0800
   From: Joe Marshall <address@hidden>

   On Sun, Dec 20, 2009 at 8:46 AM, Taylor R Campbell <address@hidden> wrote:
   > Â What I observed in MIT Scheme is that, of
   > the sixty-two uses of MAKE-EQ-HASH-TABLE, more of them are incorrect,
   > and need key-strong hash tables, than actally need key-weak hash
   > tables.

   This is what I disagree with.  If they were correct when symbols were
   strongly interned, the behavior shouldn't change when symbols are
   weakly interned.

   In other words, the *use* of MAKE-EQ-HASH-TABLE isn't the bug, it
   is the *behavior* of MAKE-EQ-HASH-TABLE that is buggy.  It should
   retain symbols and numbers the same as it used to.

Although changing symbols to be interned weakly exhibited several
problems related to eq hash tables, those cover only a subset of the
problems with using weak hash tables, only some of which are keyed by
interned symbols.  It is very surprising for hash tables to be weak by
default: that causes parts of data structures to apparently randomly
vanish.  I am not aware of any other system in which one gets a weak
hash table by asking for a hash table without explicitly requesting
that it be weak.

   BTW, the fix for this was trivial and I checked it in this morning.
   you need these two changes:

   77c8301526fc3a8f420c2922eefad215bd8d8dba (patch)
   097a3ee6c70d396a3277fb96374abbfc2da86e51 (patch)

   and now entries keyed by interned symbols will not drop out of EQ
   hash tables.  Otherwise, the behavior is as before.

Now what would happen if I made URIs weakly interned?  You would need
to change the code again, to handle URIs similarly.  Next, what about
MIME types?  That doesn't scale, and that makes every use of hash
tables harder to understand and control, because the behaviour of the
hash table on different data types is built into the abstraction, not
a part of its parameters.