I have just read Hans Boehm's POPL paper on finalizers. His suggestion for the use of finalizers in single-threaded systems is to provide a `runFinalizers' routine, instead of relying on the asynchronous execution that, as established, requires support for concurrency. I am not sure whether we have given this option really serious consideration. Why may this option be interesting? It may allow us to have Haskell finalizers after all. As Boehm explains, ``finalizers generally fall into two categories: Those that simply deallocate operating system resources and those that touch other user data structures.'' It seems that we currently, probably due to our FFI bias, concentrate on the former kind. The main benefit of Haskell finalizers, apart from convenience, is the ability to process Haskell structures. As I understand Boehm, we might adopt the following design: * Finalizers are normal Haskell routines. * When the GC discovers that a finalizer becomes enabled, it is added into a list of enabled finalizers (but not run in a single-threaded system). * When the routine runFinalizers :: IO () is called, it runs the finalizers in the list of enabled finalizers one after the other. * Systems supporting pre-emptive concurrency *may* run finalizers at any time after they become enabled, but they must run them when `runFinalizers' is called (similar to `performGC'). An attractive property of this design is that it provides a smooth transition from single-threaded systems to systems providing pre-emptive concurrency. The requirement to invoke `runFinalizers' explicitly might not be too burdensome in practice as code making heavy use of the FFI and finalizers probably spends a lot of time in the IO monad with the opportunity to insert calls to `runFinalizers'. Opinions? Cheers, Manuel PS: Sorry for bringing finalizers up again, but if there is an opportunity to improve the current design, I think, we should consider it.