Date: Sun, 20 Dec 2009 00:07:17 -0800 From: Joe Marshall <[email protected]>
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. _______________________________________________ MIT-Scheme-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/mit-scheme-devel
