I like what Simon and Alastair have written in the finalizers document. However I don't think there is any proposal I can wholeheartedly support, so I have to produce my own, which is a mixture of almost all the proposals (1)-(5). I hope though that this proposal will at least provide a framework which everyone can accept. The basic idea is that we accept that we cannot agree upon a final version of the FFI standard at this time, so we (a) make an interim change to the standard; (b) experiment with Haskell finalizers; (c) agree a method for settling discussion in a few months time. If anyone else has any better way of putting this discussion out of its misery, please let's hear it. Here is the proposal in detail: (1) We change the names of "newForeignPtr" and "addForeignPtrFinalizer" to "newUnsafeForeignPtr" and "addUnsafeForeignPtrFinalizer". This can be considered frozen and a settled part of the standard; people can start coding with them right away. (2) We also include functions newForeignPtr :: Ptr a -> IO () -> IO (ForeignPtr a) and addForeignPtrFinalizer :: ForeignPtr a -> IO () -> IO () However we should make it clear in the standard that (a) implementations only *may* choose to implement these functions, or may only implement them with restrictions; (b) the specification of these functions, or whether they exist at all, should be regarded by users as something that is particularly likely to change before the final cut. We can put this section of the standard in italics to indicate its provisional nature. (3) In the meantime Hugs, GHC, NHC should attempt to implement these functions (using for example Simon's patch) and we see how we get on, for example if there are more insuperable difficulties. (4) Also Hugs, GHC and NHC should implement PVars, with the interface newPVar :: a -> IO (PVar a) updatePVar :: PVar a -> (a -> (a,b)) -> IO b and we can see if they adequately address Alastair's concerns about mutable state (unless he already considers them adequately answered). Of course for Hugs and GHC the implementation is completely trivial, and if you can't find a student with 10 minutes to spare to write them in terms of MVars, I will be happy to oblige . . . NB. The question is not here "Are PVars the best/only possible implementation of concurrency", just "Do they provide a useful and implementable way for Haskell finalizers to communicate". NB2. If Alastair insists on "blockFinalizers" instead, I don't think we need to argue the point, but I would object to having "blockFinalizers" in the FFI standard, since blockFinalizers seems to me to make too many assumptions about the nature of the implementation (that state changes by Haskell have some sort of universal ordering for example). I would also object to having PVars in the FFI standard, since there may be a better way of implementing thread-safe common state. (5) Since perhaps we will not have unanimity even if we do all this and come back in a year, perhaps we should all agree now some decision procedure. My suggestion is that we agree now that we will either (a) cast newForeignPtr and addForeignPtrFinalizer out of the standard altogether; or (b) make them compulsory or (c) settle some alternative specification/type for them when at least two of {the NHC team}, {the Hugs team}, {the GHC team} consent. Hopefully this will not take too long, perhaps about 6 months.