"Peter Gammie" <[EMAIL PROTECTED]> 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: http://haskell.org/pipermail/ffi/2002-November/thread.html 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. -- Alastair Reid ps Note that the Eq instance I wrote is for equality of the ForeignObj container, not the contents. _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
