haskell finalisers driven underground
ger at tzi.de
Tue Feb 4 12:25:51 EST 2003
I think essentially there are only three ways you can have Haskell finalizers.
(1) every FFI implementation must implement concurrency. I'm not convinced it must
be preemptive, but at the very minimum you need some sort of concurrency, since you have
some arbitrary number of finalizers (plus the main thread) all running together, all sharing
the same space of potentially half-way evaluated values, and so all needing the ability
to go to sleep and wake up whoever is half-way through evaluation. This is a problem for
NHC, and possibly also for Hugs, so can't be done. However it is how GHC does it.
(2) allow values to be evaluated more than once. This breaks various important compiler
optimisations, and so right now is not an option for anyone.
(3) delay the finalizers until there are no half-way-evaluated values. For example,
for non-concurrent Haskells, immediately before or after a primitive IO action in the main
trunk of a program (not inside unsafePerformIO !). This would work fine for many people, like
me, but those purists who do very long pure computations without ever troubling the IO monad,
impurists who run lengthy calculations inside unsafePerformIO, or statists who do lengthy
computations in the state monad, may be surprised by the long delays before their finalizer
At the moment the consensus seems to be not to have Haskell finalizer in the standard, but leave
them up to the implementation. I think I'm secretly hoping NHC will implement (1) or (3),
forcing Hugs to bow to market forces.
More information about the FFI