hash tables and GC

[jrose@Sun.COM (John Rose)]

   Date: 22 Jul 88 10:13:34 EDT (Fri)
   From: gz@spt.entity.com (Gail Zacharias)

   Coral will have something like that in the next (major) release, although they
   probably will not be presented as hash tables.  Letting you map over them is
   actually ok, although you have to be aware that just because you put something
   in one once doesn't mean it'll still be there when you map over it later.
Sometimes that's "OK", sometimes not.  For example, if a hash table is being
used as a relational database (with a primary key indexed by the hash table),
you probably don't want tuples therein to be GC-able.

Therefore, it's wise not to present them as hash tables.

   This isn't much different from do-all-symbols in a lisp which does gctwa.
I believe only the simplest symbols should be GC-ed; if a symbol is
interned and has a nontrivial plist (say), GC-ing it will change
the visible behavior of the program, since if a program re-creates
it (via INTERN or READ), it will be missing its plist.

Similarly, if hash table keys are being used to store information,
as well as merely access it, they shouldn't be GC-ed.

Putting weak links to keys in hash tables would make the EQUAL semantics
I proposed impossible, since an isomorphism test depends strongly
on MAPHASH.  (Or, before EQUAL is applied to test for isomorphism,
normalize the two tables by performing a full GC! :@)
Weak pointers are probably more useful than EQUAL isomorphism tests,
but a reliable MAPHASH also seems indispensible.  Sounds to me
like weakly-linked keys want to be another option to
MAKE-HASH-TABLE.

				-- John