Date: Sun, 20 Dec 2009 07:55:07 -0800 From: Joe Marshall <[email protected]>
It seems to me that a weak internment scheme should not be observably different from a strong one in any way. It should only be (potentially) more memory efficient. This implies that if weakly interned objects are used as keys in a hash table, then the entries they map to must be preserved under all circumstances. Generally, unless I explicitly request weak references, I expect the parts of my data structures -- whether they be hash tables, weight- balanced trees, lists, &c. -- not to vanish automatically under any circumstances, irrespective of what objects I put in them. Whether programs that use weak references can observe a difference between a weak internment scheme and a strong internment scheme -- which is something that programs using only strong references, of course, can't observe -- is a separate issue. A weak-key EQ hash table should not be observably different from a strong one with regard to the put and get operations. It may be observably different in the count and key-list operations, that is, inaccessible entries would be allowed to drop out. If the user doesn't want this, he should use an EQUAL hash table. I agree with every sentence in this paragraph except for the last one. There already is a way to make a key-strong eq hash table, called MAKE-STRONG-EQ-HASH-TABLE. 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. (There is a large number for which it doesn't really matter, or for which a key-weak hash table pretty much only accidentally works.) This led me to the conclusion that MAKE-EQ-HASH-TABLE is a confusing name. _______________________________________________ MIT-Scheme-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/mit-scheme-devel
