Now that Joe has "fixed" the handling of interned symbols, we should address the more general problem that Taylor is concerned with.
The documentation clearly states that make-eq-hash-table returns a weak table, and has so stated for a long time. So it's not reasonable to change the semantics overnight. Here's what I propose: * Add a new binding make-weak-eq-hash-table (and make-weak-eqv-hash-table, which you haven't mentioned but which should also be done). * Change the documentation to recommend that programmers use the explicit name to guarantee a particular semantics, and to warn that make-eq-hash-table may change its semantics from weak to strong in the future. * Change our code base to use the explicit names in all cases. * File a bug report, referring to or attaching this discussion. * Optionally, add a compiler warning when make-eq-hash-table is used. * Sometime down the road, in a couple of years, close the bug report by making appropriate changes. OK? On Sun, Dec 20, 2009 at 2:54 PM, Taylor R Campbell <campb...@mumble.net> wrote: > Date: Sun, 20 Dec 2009 13:48:59 -0800 > From: Joe Marshall <jmarsh...@alum.mit.edu> > > On Sun, Dec 20, 2009 at 8:46 AM, Taylor R Campbell <campb...@mumble.net> > 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 > MIT-Scheme-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/mit-scheme-devel > _______________________________________________ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org http://lists.gnu.org/mailman/listinfo/mit-scheme-devel
