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

[Charles Fiterman]

First this has nothing to do with uncooperative environments
where you must make some very ugly compromises.

But let us suppose we are designing a language with both
Garbage Collection and Finalization. Suppose we are starting
fresh with no moldy LISP programs to support.

If an object has a finalizer that finalizer must be executed 
and executed promptly. For example suppose a function starts
by turning on a motor or allocating a file handle. If we have
a finalizer to turn off the motor or deallocate the file handle
it is vital that the finalizer be executed and executed promptly.
It cannot wait for the next collection cycle or the end of job.

I propose having finalizer dependencys a separate data structure.
The existence of an object on this structure will keep it alive
as far as the garbage collector is conserned. Something is pointing
to it, the finalizer structure, so it cannot be collected until
that structure is done with it. No different from any other data
structure.

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.

Here I am wide open to suggestion. But here is the best I have found.

Now C++ allows references to be set only when they are constructed.
This is occasionaly ugly and is tolerable because there are pointers
which can be set and compared any time. I propose allowing pointers
to objects with finalizers to be set only only in constructors or
if they are inside of objects who`s use is guaranteed LIFO such as
execution frames guaranteed to act in a LIFO fashion, that is no
generators. These pointers to objects with finalizers can then drive
reference counters in the objects they point to.