Finalizers compromise

[George Russell]

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.