Issue: HASH-TABLE-GC (no proposal)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Mon, 17 Oct 88 20:19:26 PDT
    From: Jon L White <jonl@lucid.com>

    ... Anyone else know of other "actual needs"?

I run into cases all the time where these would be useful. Here are a few...

 - My portable error system needed weak hash tables for unique ids
   in printing (in order to simulate MAKNUM in a portable, reliable way).

 - In my work with Cloe (internally at Symbolics), I've had need to
   record various kinds of attribute information about non-symbols.
   An example is the keeping of :ADJUSTABLE information in the Cloe
   development environment (since Genera doesn't represent that info
   explicitly and some users want to be able to have ADJUST-ARRAY
   do error checking anyway).

 - Also internally to Cloe, before I'd worked out a way to have
   funcallable things with slots, I had hash tables from function
   objects to another structure which had the slots. The function was
   also closed over the structure with slots, so it didn't go through
   the hash table, but the hash table was important in debugging.

All of these items need hash table with weak key links only.
All of these items cause the accumulation of massive amounts of
garbage over time with no (semantically valid) hope of recovery
in the absence of weak hash tables.

It is especially important to provide an abstraction for dealing with
this kind of thing in a portable language because often the problems
are caused by portability. That is, most of these problems can be solved
within an implementation by ways better than weak hash tables. Eg, -- if
I knew all kinds of useful stuff about the internals of the Lisp in
question -- I would just implement MAKNUM, add an extra bit in arrays,
or make a new data type for generic functions. That being the case,
there is far less motivation to -ever- develop weak hash tables in any
given implementation.

Yet problems that demand this sort of solution continue to hit people
who have no access to such low-level/bit-twiddly solutions. So I agree
with GZ that it's a little unfair to ask who has a use without first
providing it. For all we know, lots of hash tables in use today could
be needless storage hogs because programmers really wanted weak tables
and couldn't find them -- and were willing to pay the storage penalty
of using normal hash tables because the application was so important.

There may be some little details to attend to, but abstractly the idea
of a table with weak key links is both simple and powerful. I think we
should look at the idea quite seriously. The question I have for those
who think it's premature to do this is: what is the worst case scenario
you can imagine for introducing this feature prematurely? Are you
envisioning a feature that is hard/expensive to implement? unreliable
in some way I'm not thinking about?  turns out to not be something
people want? Are the objections technical, economic, cultural ... or
superstitious?