When it comes down to it, I don't think we are that far apart. 1. Everyone wants a C-finaliser interface; it's very convenient. So it should be in the spec. It's probably a good plan to specify that such C finalisers must obey the constraints of an 'unsafe' foreign import. 2. It is clear that GHC at least will offer a Haskell-finaliser interface, and that some people will use those Haskell finalisers; they already do. So it's desirable that they should be in the FFI spec so that there's a standard for what they look like. 3. We do not want the spec to require mutable state or concurrency, and indeed Haskell finalisers make sense (albeit are much less convincing) without such extensions. Still, I think the spec should warn explicitly that in the presence of mutable state care must be taken by the programmer, because the finaliser can run at any time wrt the "main program". 4. The spec makes no guarantees about promptness. Each implementation may want to add notes about promptness. For example, Hugs will say that C finalisers will run much more promptly than Haskell finalisers (if it supports the latter at all). I think that the only real point of difference is that Alastair would rather we did not even specify Haskell finalisers in the FFI spec, because doing so encourages non-portability. I don't agree about that; I think people will use Haskell finalizers anyway, so we should specify them. Simon