[gclist] gc interface

[Stefan Monnier]

> First finalization should not be encapsulated with garbage collection!
> Garbage collection deletes objects when they can have no further effect
> on execution. Finalization effects execution. So for the Garbage collector
> to call a finalizer is deeply wrong. Garbage collectors run lazily if
> at all and need to be efficient. Finalizers need to be prompt and sure.

Am I the only one to think that "Garbage collection deletes objects when they
can have no further effect on execution" is not obvious at all ?
As I see it, GC cleans up objects when they are not reachable any more by
the mutator. The default cleanup function being simply "free".

I know that the R4RS defines the GC as a somewhat optional component which
should not alter the behavior of the program (ignoring its memory-footprint),
but I'm not sure whether this view was expressed for lack of interest in
finalization-like tricks, for beauty's sake or really because that's
what "GC was meant to be".

Sometimes you might prefer explicit destructors or any other "synchronous"
cleanup system, but finalization, as I see it, is deeply bound into GC.

Aside note: finalizers don't have to have visible effects on execution.
For instance, finalizers which close files before freeing memory can probably
be considered as "effect-free" (ignoring the filehandle-footprint).

It's probably good practice to avoid "loud" finalizers which have an important
effect on the mutator, especially since you never know when (or if) a finalizer
will be called. So you end up writing mostly "effect-free" finalizers.

If you need a finalizer that's "prompt and sure", you probably need something
else since what is usually named "finalizer" is has no promptness guarantee.
A finalizer should be merely an optional optimisation.


	Stefan