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

[Taylor R Campbell]

   Date: Sun, 20 Dec 2009 00:07:17 -0800
   From: Joe Marshall <address@hidden>

   Ignoring the issue of weak symbols for the moment, there is no need
   to have strong references to the keys *unless* someone is depending
   upon walking the hash table to find them.  (and they shouldn't)

I don't buy `they shouldn't' unless we're prepared to eliminate
HASH-TABLE/KEY-LIST, HASH-TABLE/DATUM-LIST, HASH-TABLE/FOR-EACH, &c.,
and then rewrite everything that uses them to use a different
abstraction.

   Interned objects that can be recreated from their print names (that
   is symbols, numbers, and other symbol-like things such as hostnames
   and/or URLs) should be treated as strong keys, but other objects
   that cannot be re-created (like cons cells) should not be strong.

How do I make new types of interned objects?  For example, suppose I
want to implement a hash consing scheme for expressions in a certain
symbolic algebra system to speed up my job as a celestial mechanic.
The hash table abstraction as is doesn't provide any way for me to
tell it what types of keys should be weakly held and what types of
keys should be strongly held for key-weak hash tables.

Of course, in order to make new types of interned objects the right
way, I really need a datum-weak, not key-weak, association collection,
which the current hash table abstraction doesn't provide -- although I
think it should.  And I'd much rather implement that than implement
some hook into the hash table abstraction for instructing it what to
automatically treat with strong references and what to automatically
treat with weak references -- such a hook would make the abstraction
harder to understand and probably still more error-prone.