Alastair Reid <[EMAIL PROTECTED]> wrote, > Ashley: > > How do I create a new ForeignPtr that doesn't have any finalizers? > > Malcolm: > > Why would you want to? > > addForeignPtrFinalizer lets you add them later. > I'm guessing that Ashley is making heavy use of this ability. > > [What we have at the moment is the ability to attach a non-empty list of > finalizers to an object. I don't immediately see a use for an empty list but > my experience with various datatypes is that it is usually cleaner to allow > the empty or zero case and I#'m hoping that Ashley will demonstrate how it is > useful...]
Andre Pang here in his work to hook Haskell up with ObjectiveC also found a need for foreign pointers without a finalizer. (Essentially, because there are two sorts of foreign objects only one of which is reference counted, but he otherwise wants to handle both sorts uniformly in the binding.) To create foreign pointers without a finalizer, I like Alastair's newForeignPtr_ :: Ptr a -> IO (ForeignPtr a) Andre proposed to allow `nullFunPtr' as a finalizer argument to `newForeignPtr' to indicate the lack of a finalizer. This seems quite C-ish, but has the advantage that it is easy to parametrise functions that internally use `newForeignPtr' as to whether there should be a finalizer attached. I guess, the FP-ish solution is to pass an argument of type `Ptr a -> IO (ForeignPtr a)' which is `newForeignPtr_' if no finalizers should be attached and is `newForeignPtr' already applied to a finalizer if a particular finalizers is to be attached. However, then, it would be more convenient to change the order of the two arguments to `newForeignPtr'. Malcolm Wallace <[EMAIL PROTECTED]> wrote, > Ashley Yakeley <[EMAIL PROTECTED]> writes: > > > Specifically I want a ForeignPtr of a null Ptr that has no finalizers. > > Ah, this makes sense. > I wonder if we should add the following to the FFI spec module ForeignPtr? > > nullForeignPtr :: ForeignPtr a -- a null pointer with null finalizer This is easily implemented with `newForeignPtr_': nullForeignPtr = newForeignPtr_ nullPtr Summary ~~~~~~~ I'd propose to * add `newForeignPtr_', * reverse the argument order to `newForeignPtr', and * reverse the argument order to `addForeignPointerFinalizer' (for consistency). Unfortunately, this is going to break code again. Cheers, Manuel _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi