[gclist] Destructors in a heap oriented language.

[Charles Fiterman]

Let us assume that destructors are important. That the program needs
to run them and do so quickly or it is buggy. A good example is a
file handle leak which is clearly worse than a storage leak.

I think the trick is to establish stack semantics for objects with
destructors.

1) When a pointer is aimed at an object with a destructor its reference
   count goes up when the pointer is reaimed or destroyed the reference
   count goes down and zero count destroys the object. Straight reference
   count semantics.

2) Any object with a destructor or a pointer to an object with a
   destructor is considered an object with a desturctor so the pointer`s
   destructor`s can be called.

3) Pointers to objects with destructors are either in the static area
   or in other objects. If they are in other objects they can be set
   in constructors but never reset. Pointers in the static area
   can be reset, triggering destructor calls. At end of job the
   static data area is destroyed.

This gives two kinds of storage, reference count for objects with
destructors and garbage collected for objects without. At no point
can circular reference be created. No actions take long sequences
to complete.