[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MIT-Scheme-devel] make-eq-hash-table
From: |
Taylor R Campbell |
Subject: |
Re: [MIT-Scheme-devel] make-eq-hash-table |
Date: |
Sun, 20 Dec 2009 11:46:50 -0500 |
User-agent: |
IMAIL/1.21; Edwin/3.116; MIT-Scheme/7.7.90.+ |
Date: Sun, 20 Dec 2009 07:55:07 -0800
From: Joe Marshall <address@hidden>
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] make-eq-hash-table, Taylor R Campbell, 2009/12/20
- Re: [MIT-Scheme-devel] make-eq-hash-table, Arthur A. Gleckler, 2009/12/20
- Re: [MIT-Scheme-devel] make-eq-hash-table, Joe Marshall, 2009/12/20
- Re: [MIT-Scheme-devel] make-eq-hash-table, Taylor R Campbell, 2009/12/20
- Re: [MIT-Scheme-devel] make-eq-hash-table, Joe Marshall, 2009/12/20
- Re: [MIT-Scheme-devel] make-eq-hash-table, Taylor R Campbell, 2009/12/20
- Re: [MIT-Scheme-devel] make-eq-hash-table, Joe Marshall, 2009/12/20
- Re: [MIT-Scheme-devel] make-eq-hash-table,
Taylor R Campbell <=
- Re: [MIT-Scheme-devel] make-eq-hash-table, Joe Marshall, 2009/12/20
- Re: [MIT-Scheme-devel] make-eq-hash-table, Taylor R Campbell, 2009/12/20
- Re: [MIT-Scheme-devel] make-eq-hash-table, Chris Hanson, 2009/12/20
- Re: [MIT-Scheme-devel] make-eq-hash-table, Arthur A. Gleckler, 2009/12/20
- Re: [MIT-Scheme-devel] make-eq-hash-table, Taylor R Campbell, 2009/12/20
- Re: [MIT-Scheme-devel] make-eq-hash-table, Chris Hanson, 2009/12/21
- Re: [MIT-Scheme-devel] make-eq-hash-table, Taylor R Campbell, 2009/12/21
- Re: [MIT-Scheme-devel] make-eq-hash-table, Chris Hanson, 2009/12/21
- Re: [MIT-Scheme-devel] make-eq-hash-table, Taylor R Campbell, 2009/12/21
- Re: Re: [MIT-Scheme-devel] make-eq-hash-table, eval . apply, 2009/12/22