alastair at reid-consulting-uk.ltd.uk
Tue Dec 10 13:29:54 EST 2002
"Peter Gammie" <peteg at cse.unsw.EDU.AU> wants:
> a general "stick this arbitrary (small) C object in an
> optimiser-impervious box" generalisation of ForeignPtr.
Simon Marlow writes:
> There was a proposal for such a thing kicking around recently, and I
> think there's no real problems with it.
The discussion was in the 'ForeignPtr' thread back in November:
There's several designs that are variants on:
data ForeignObj a -- abstract
instance Eq (ForeignObj a)
type Finalizer a = FunPtr (a -> IO ())
newForeignObj :: a -> Finalizer a -> IO (ForeignObj a)
addFinalizer :: ForeignObj a -> Finalizer a -> IO ()
withForeignObj :: ForeignObj a -> (a -> IO b) -> IO b
touchForeignObj :: ForeignObj a -> IO ()
[A variant on this is to have a 'Finalizable' constraint on the type
variable 'a' but I'm not sure why we need this. Also, I'm not sure
what the status of the 'touch' operations is these days - IIRC, the
GHC folk say it is hard for them to implement correctly.]
I think it makes sense to do this or something very like it. We
really ought to have done this when we switched from 'Addr' to 'Ptr a'
but we misgeneralized.
ps Note that the Eq instance I wrote is for equality of the ForeignObj
container, not the contents.
More information about the FFI