[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: HASH-TABLE-GC (no proposal)
- To: Moon@STONY-BROOK.SCRC.Symbolics.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM
- Subject: Issue: HASH-TABLE-GC (no proposal)
- From: Jon L White <firstname.lastname@example.org>
- Date: Tue, 18 Oct 88 11:54:10 PDT
- Cc: Gregor.pa@Xerox.COM, email@example.com, CL-Cleanup@SAIL.Stanford.EDU
- In-reply-to: David A. Moon's message of Tue, 18 Oct 88 00:29 EDT <19881018042934.6.MOON@EUPHRATES.SCRC.Symbolics.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
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.