In fairness I should state that here at Bremen we do not currently need Haskell finalizers. I was thinking of another application altogether, but I don't particularly want to go into details of that. There are however particular reasons (such as galloping concurrency) why I think Alastair's proposed hooks would be impractical in that case, even if they were provided by both garbage collectors, which they wouldn't be. I don't think we are coming any nearer to a solution on this. There seem to be three proposals: (1) Alastair's: keep the signature as it is, with the restriction. Add miscellaneous hooks allowing C to do things to the Haskell world without actually entering it. (2) Mine: keep the signature as it is, but remove the restriction, at least so that if implementations decide to impose the restriction anyway, they have to document it very clearly. (EG "Hugs implements the FFI standard [ref]" with the restriction that finalizers may not call back into Haskell (see paragraph [whatever]"). (3) Manuel's: reverse the change altogether. Ideally I'd like Manuel's solution, except that we obviously can't force Hugs and NHC to comply with it. I think therefore I prefer my solution in that it makes clear you can write simple portable FFI code which runs on any implementation with or without the restriction, but non-trivial use involving interaction with foreign garbage collectors and the like is likely to fall over. I don't deny that it is likely to be possible to write non-trivial applications involving finalizers in several languages even in Hugs, but you will have to provide various hooks which are in general quite inappropriate. Other choices might be some kind of lock which could be operated from both the Haskell and C world (since then it would be possible, painfully, for a C finalizer to arrange for a Haskell thread sleeping on the lock to wake up, if enough scheduling points arise). Or as Alastair suggested, you can at least arrange for some Haskell functions, like freeStablePtr, to be made available in the C world. Such things might be a good idea in Hugs or NHC (obviously it's not for me to say), if Haskell finalizers really are impossible. But in general I think it is simply absolutely inappropriate for such solutions to be specified in the standard, since they seem to assume too much and impose too much work on the user, if the user is happy to use GHC.