new ForeignPtr without finalizers

[Manuel M T Chakravarty]

Dean Herington <heringto at cs.unc.edu> wrote,

> On Thu, 12 Jun 2003, Alastair Reid wrote:
> 
> > Manuel:
> > > In other words, it seem much more likely that one would
> > > partially apply `newForeignPtr' to a finaliser than to a
> > > pointer that is to be finalised.  But this is a minor point.
> > 
> > Having written some more ffi code over the last couple of days, I agree that 
> > this is much more natural so, even though it will break all the packages I 
> > released in the last week, I now vote for swapping the argument order.
> > 
> > Since this breaks code anyway, we could adopt Dean's proposal to allow lists 
> > of arguments to newFP and addFPFinalizers without making things worse.  I 
> > don't think we should do this though since I believe they would always be 
> > used with singleton or empty arguments and because the list-based versions 
> > can be trivially added with a foldM if they prove useful.
> 
> Actually, I think I prefer Ashley's idea of separating the creation of a 
> ForeignPtr from the addition of a FinalizerPtr.  So how about:
> 
> newForeignPtr              :: Ptr a -> IO (ForeignPtr a)
> addForeignPtrFinalizer     :: FinalizerPtr a -> ForeignPtr a -> IO ()
> 
> newForeignPtrWithFinalizer :: FinalizerPtr a -> Ptr a -> IO (ForeignPtr a)
> newForeignPtrWithFinalizer f p = do p' <- newForeignPtr p
>                                     addForeignPtrFinalizer f p'
>                                     return p'

This is what is in RC 11, just with other function names.

Manuel