[gclist] Finalization and collection should be separatly encapsulated..

[Charles Fiterman]

> > Now the only data structure I can find that fills the bill is
> > an acyclic graph. The question is what is the most natural and
> > least intrusive way of being sure the acyclic graph stays acyclic
> > through modifications. The method cannot require massive overhead
> > to change the graph. This will make more restrictive than the
> > acyclic requirment.
> 
> Not unsurprisingly, you'll find that one solution is to impose a stack
> without forwards pointers. It's like imposing a total order where a partial
> order suffices, but it makes for extremely light-weight code and is impressively
> simple and probably fits most uses.

A tree is just as simple to maintain and fits even more uses.

The question is how general can we get and still be simple and intuitive.

But I am convinced that finalization and collection need separate
encapsulations. First because finalizers need to be called promptly and
collectors are poor at that. Second because a collector deletes objects
when they can no longer effect program execution. Calling a finalizer
at that point effects execution. This is inherently sinful and the
penalty of sin only death if you are lucky, otherwise its incorrect output.
Third these are natural things to separate if you control the language.
Fourth separating them allows them to be experimented with independently.
Fifth finalization seen as the maintence of a data structure etc looks
like a high level notion that something like CLOS would allow different
implementations of.