[gclist] Destructor FAQ

[Robert A Duff]

> Here I don`t see how an already finalized object has a usable state.
> A finalized file object is closed. That may be well defined but
> using it is a problem. Perhaps we could distinguish between finalized
> objects left in a usable state and those left in a useless state.
> This would allow simplification of finalization dependencies for
> the former but not the later.

It's true that writing to a closed file is a bug.  That's true with or
without finalization.  It's the programmer's responsibility to make sure
it doesn't happen.  You can even use an if statement to check whether a
file is open.  I don't see this as the language's responsibility.  The
language should just give you tools for defining the order of
finalization in a clean way.  The cleanest way I can think of, is the
simple stack-based mechanism of languages like C++ and Ada.

In Lisp, the language doesn't prevent you from ever seeing NILs, but it
gives you tools for checking whether something is NIL in a well-defined
manner.  Now NIL is fairly useless -- you can't write data to it and so
forth.  But it's not *totally* useless (you can check whether something
is NIL), and anyway the important thing is that the semantics of NIL is
well-defined.

> But cleanly separating finalizers from collection solves so many
> problems.

True.  I guess in a sense we're saying the same thing.  If you allow me
to have heap-based cyclic structures containing finalizers, I probably
won't use that feature much, precisely because it makes the timing of
finalization so unpredictable.  But I don't see how this implies that
one needs an elaborate set of rules *preventing* such uses.

Can anybody think of a realistic example in which a cyclic structure has
some pieces with finalization?  I can't right now.

- Bob