Alastair Reid <[EMAIL PROTECTED]> wrote, > Since requiring ForeignPtr.newForeignPtr would require preemptive > concurrency (see previosu discussion), I propose the following changes: > > 1) Add these functions: > > makeForeignPtr :: Ptr a -> FunPtr (Ptr a -> IO ()) -> IO ForeignObj
I assume you meant makeForeignPtr :: Ptr a -> FunPtr (Ptr a -> IO ()) -> IO (ForeignPtr a) > attachForeignPtrFinalizer :: ForeignPtr a -> FunPtr (Ptr a -> IO ()) -> IO () What do you expect to happen if the finaliser calls a foreign exported function? (I am sorry, but I still haven't been able to closely look at the entire ForeignPtr discussion, so maybe this question was already answered there.) > 2) Remove newForeignPtr and addForeignPtrFinalizer > > Two variants on this proposal: > > 1) Reuse the old function names instead of inventing new ones. > > I don't care much either way. That's a tricky one. From the standards point of view, I am actually *very* reluctant to introduce new names. On the other hand, reusing the old names will lead to a couple of unhappy emails from people using the old interface again. Maybe we should have an -package old-ffi for compatibility. > 2) Instead of removing the old functions, rename them and mark them > as an optional extra. > > I think this would be a mistake - the GHC documentation is the > right place to mention extensions which are not available on all > ffi implementations. We have avoided optional extras so far and I don't see a reason to deviate from that policy now. Moreover, it is easy to define the old interface in terms of the new one that you propose (given you can handle callbacks in finalisers). Cheers, Manuel _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
