[gclist] Re: Mark don't sweep

[Amit J Patel]

Charles Fiterman wrote to me on May 10:
> > 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.

No, I don't expect the finalizer closures to refer to the other
elements of the list.  The dependency is then broken.  (I could
enforce this statically.)

> > 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.

Why does this belong in a MOP?  

> > 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 too have seen several things in OOD literature about distinguishing
between HAS-A (containment) and REFERS-TO (reference).  If you
distinguish between these two things in your mind/design, why not
distinguish in the language?  The distinction might help in defining
finalizers.  

(I should ask the designers of C: if you distinguish between numbers
and characters in your mind, why not distinguish between them in the
language?)

> > 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.

The trouble is .. are there any *guarantees* that the partial
evaluator will find the difference, and can you do things differently
with the two types of fields?

If the two are to be treated different semantically (with HAS-A fields
allowed in finalizers, and REFERS-TO not), then you should distinguish
between them in the language, IMO.


	- Amit



-- 
Amit J Patel, Computer Science Department, Stanford University
             "The works of a lone architect are more elegant 
              than those attempted by several together."    - Pascal