mit-scheme-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: eval . apply
Subject: Re: Re: [MIT-Scheme-devel] make-eq-hash-table
Date: Mon, 21 Dec 2009 00:37:10 +0000

On Dec 20, 2009 2:54pm, Taylor R Campbell <address@hidden> wrote:
>
>  It is very surprising for hash tables to be weak by
> default: that causes parts of data structures to apparently randomly
> vanish.

I could argue that it is very surprising for *symbols* to be weak
by default. It causes parts of data structures (in particular, the obarray)
to apparently randomly vanish.

Suppose someone had written some code that interns
strings with the intent of retrieving them later from the obarray. The change
you made to make weak symbols will cause this code to break. Someone
might be pretty upset that parts of the data structure are randomly
vanishing.

Of course the response to this is that the obarray isn't intended to be
used in this manner. It is not guaranteed
to retain symbols and that it was simply an implementation detail that
it happened to retain them. And user code should not assume that
calling intern on a symbol will cause it to appear in the obarray.

I argue the same is true of hash tables. User code should not assume
that inserting a key/value pair in the table will cause the key to appear
in the key-list.

Basically, if I do this:

(hash-table/put! my-eq-table (cons 'a 'b) 'hello)

There is no possible way for me to retrieve the value from this table
with hash-table/get because I cannot regenerate the key. Therefore,
the entry itself is useless because no one can access it. So it need
not be in the table.

If you are writing code that assumes the key list
*will* retain the mapping even if no one else will, then you are doing
the equivalent thing to using the obarray to retain symbols that no one
is using. (You're relying on an accident of implementation that would
be better served by simply consing a list!)

> 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?

This has been an issue in lisp for close to 50 years
(see http://home.pipeline.com/~hbaker1/ObjectIdentity.html )
I think the solution is probably to differentiate between the weak links to
hash-table values and the weak links to hash-table keys and make the GC
smarter about them. You could then write your URI's to be weakly interned
(as hash table values) and this would protect them from dropping out of weak
keyed tables.
reply via email to

[Prev in Thread] Current Thread [Next in Thread]