Date: Sun, 20 Dec 2009 13:48:59 -0800 From: Joe Marshall <[email protected]>
On Sun, Dec 20, 2009 at 8:46 AM, Taylor R Campbell <[email protected]> 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. _______________________________________________ MIT-Scheme-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/mit-scheme-devel
