Issue: HASH-TABLE-GC (no proposal)

[Jon L White <jonl@lucid.com>]

re: Date: Tue, 18 Oct 88 00:29 EDT
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    . . . 
    In Genera ... The identified, actual need was internal to Statice 
     (an object-oriented database system).  ...

The "actual need" identified at the CLOS symposium was Larry Rowe's
object-oriented database work Picasso -- the management of "in-core
handles" for external, database stored objects.  I'd hazard a guess
that the Statice need was basically the same, namely a need for
"cache tables".  Probably Gregor's suggestion for "Network Resource
management like in X implementations" would fall into the same class,
as would Gail's mention of "maintaining some auxillary debugging info".


re: Date: Tue, 18 Oct 88 13:42 EDT
    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
    . . . 
     - 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).

     - [third case similar to second -- JonL]

This looks more like a need for attribute properties rather than for
"cache tables";  I'm not sure of how you, and others (such as pop11),
would use them, but it probably would be unacceptable for "lightening"
to strike haphazardly and delete random entries (as "cache tables" were
so graphically characterized).  Likely, Gail's mention of "keeping track
of editor marks" falls into this class.  Perhaps Dalton can shed some more 
light on the dynamics of such properties?

Incidentally, the design of VAX/NIL had to encompass a MAKNUM for
MacLisp compatibility; and we more-or-less talked ourselves into
believing that a single "unique id" table, specially handled by the
garbage collector, was satisfactory for all such usages.  That is, 
any desired "weak property" could be hung off the unique-id slot;
and all such properties would "go away" when the object was GC'd.
[See P.S. below about MacLisp semantics.]


In response to Gail and Kent's comment that it is unfair to ask for
"actual need" situations:  this question is motivated by the prospect 
of including such a feature in the upcoming standardard, not in regard
to any implementor's design.  In fact, my msg explicitly suggested that
standardization should come only after some implementation's lead in 
utilization.  I firmly believe in vendors making innovative extensions 
to the standard.

The meta point in this discussion is the "why" we are assembled into 
X3J13.  I call it the Moon-Gabriel-Weinreb-White viewpoint, that we
are standardizing an old, existing language -- not designing a new 
language without regard to an existing community of users.  Common Lisp
is the culmination of 30 years of Lisp development for AI research and 
commercial use; other dialects of Lisp are newer, and do better serve 
the purposes of Programming Language research.  There is certainly 
room in X3J13 Common Lisp for incompatible changes and novel additions;
but we simply should be MUCH MORE conservative about the speed of 
acceptance of these than we are about, say, fixing up clear ambiguities 
in our former understanding and extending the unfinished work that was 
overdue even in 1981 when the unification movement began [i.e., object-
oriented-programming/Flavors, Iteration/LOOP, Windows(sigh) and 
Compilation Semantics].

Hence, I look forward to "weak" tables etc in Common Lisp, but not
in January 1989.



-- JonL --



P.S. Reminder for those not familiar with MAKNUM -- since pdp10 MacLisp
     had a "collecting, non-relocating" garbage collector, the address 
     of any object was it's unique id; but for implementations using some
     form of copying garbage collector, either an extra slot in each 
     object had to be reserved for this purpose, or else some kind of 
     "weak" property table had to be maintained by the GC.  I think 
     Multics MacLisp had a special table for MAKNUM, but maybe entries 
     never got deleted; Moon may remember.