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 <campb...@mumble.net> wrote: > Date: Sun, 20 Dec 2009 15:21:20 -0800 > From: Chris Hanson <c...@chris-hanson.org> > > 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? > _______________________________________________ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org http://lists.gnu.org/mailman/listinfo/mit-scheme-devel
