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

[Chris Hanson]

I agree with most of your analysis.  Here are my comments:

*** edwin/eystep.scm, ynode-regions

What are the keys to these hash tables?  I don't know how long they
persist.

****************
The keys are stepper nodes; they are stored in a text property and
consequently will be held appropriately.  This should be a weak table.

*** edwin/win32.scm, event-handlers

The keys in EVENT-HANDLERS are integers.  I think this should be a
key-strong eqv hash table rather than a key-weak eq hash table.

****************
For numbers, it doesn't matter, but strong is slightly lower overhead.

*** edwin/xterm.scm, symbol->x-atom table in display/cached-atom-tables

Whether this should be key-strong or key-weak depends on whether the
set of atoms that it will map is arbitrarily large.

****************
This table should be strong.

*** xml/xhtml-entities.scm, table in html-char->name-map

The keys in the table inside HTML-CHAR->NAME-MAP is keyed by
characters.  Should this be a key-strong eqv hash table rather than a
key-weak eq hash table?

****************
Again, it doesn't matter, but strong is lower overhead.

*** xml/xml-names.scm

This is hairy: part of it looks like it needs to be datum-weak, but we
don't have that now.  But someone more familiar with the XML name
abstraction should review this.

****************
All three tables should be weak.


On Sun, Dec 20, 2009 at 5:29 PM, Taylor R Campbell <address@hidden> wrote:
>   Date: Sun, 20 Dec 2009 15:21:20 -0800
>   From: Chris Hanson <address@hidden>
>
>   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:
>
>   [...]
>
>   OK?
>
> Sounds good to me.  I have gone through the list I made earlier and
> updated some of my analysis.  Since there were so many cases and my
> analysis was very shallow, I am not yet comfortable committing changes
> reflecting the analysis.  Would anyone care to review the list, the
> updated version of which I have attached?
>