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

[Chris Hanson]

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 <address@hidden> wrote:
>   Date: Sun, 20 Dec 2009 13:48:59 -0800
>   From: Joe Marshall <address@hidden>
>
>   On Sun, Dec 20, 2009 at 8:46 AM, Taylor R Campbell <address@hidden> 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
> address@hidden
> http://lists.gnu.org/mailman/listinfo/mit-scheme-devel
>