[gclist] Re: Mark don't sweep

[Charles Fiterman]

> I have a slightly different view of the finalizers:  I view them as
> functions that must be run before the program ends, but the time at
> which they are executed is not determined.  The only guarantee is that
> the function is executed between the point that the object becomes
> garbage and the end of the program.

How do you make this guarantee. Suppose there is a 1000 element list
with finalizer dependencies. To run the finalizer on the 1000th 
element requires 1000 collection cycles. Do you really intend this.

> (I don't expect any deep chains in my system.)

This is ok for a system but not a language.

> > A loop of finalizer objects can never die.
> 
> True.
> 
> I'd call it a `programming error' to write a program that has a loop
> of finalizer objects.  ;) I don't have enough experience with
> finalizers to make this judgement, however.  :(

It is definately a programming error. The problem is either to make
the system safe against such errors or at the very least to report
them. No collection system does either. 
 
> My intended use of finalizers in this OO language, however, is not for
> loops: it is for `containment' of objects.  If a Car contains a Tire,
> then the finalizer for Car might do something to Tire.  It's not for
> `refers to' fields of objects.  If a Car refers to its Owner, the
> owner is not part of the car; the finalizer should not do anything to
> the owner.  In such a system, there can be no loops, and chains can be
> bounded statically (because no object would contain an object of the
> same class, even though it may refer to an object of the same class).

This is a good convention to prevent loops. It belongs in a meta object
protocol not the language. I hope you look at CLOS it might prevent
your building a language.
 
> Perhaps the language should distinguish between these two types of
> object fields.  HAS-A relationships would be acyclic, and the
> contained object could be contained in only one other object.
> REFERS-TO relationships could be arbitrary.

There is a lot of literature on this in SIGPLAN notices.

> I'm not sure what partial evaluation can do for finalizers.  (Did I
> miss something?)

Partial evaluation allows you to run parts of your program at compile
time. This improves the complexity of what you can put in the Meta
Object Protocol. For example with your HAS-A and REFERS-TO conventions.
In a partial evaluator if the type info required to make such distinctions
are available at compile time they will run at compile time.

I regard compile time type systems as partial evaluation of the type
information of the program. But there are lots of things that can be
partially evaluated other than type systems. I never want to hear
"Is there a programmer aboard the aircraft? I'm getting the message
divide by zero error and I'm only trying to land." Partial evaluation
can be used to prevent some errors from occuring at run time by
flagging where they could occur.