Re: new ForeignPtr without finalizers
Dean Herington [EMAIL PROTECTED] wrote, Alastair Reid wrote: I'm not convinced that merging them into a single function is desirable, but, if we wanted to, I think a better FPish solution is to use Maybe (FinalizerPtr a) As multiple finalizers are allowed, perhaps we should consider: newForeignPtr :: [FinalizerPtr a] - Ptr a - IO (ForeignPtr a) addForeignPtrFinalizers :: [FinalizerPtr a] - ForeignPtr a - IO () True, but it would also break old code and I doubt that users would often add more than one finaliser at a time. Cheers, Manuel ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: new ForeignPtr without finalizers
Alastair Reid [EMAIL PROTECTED] wrote, I'd propose to * add `newForeignPtr_', * reverse the argument order to `newForeignPtr', and * reverse the argument order to `addForeignPointerFinalizer' (for consistency). I agree with adding newForeignPtr_. (Presumably the report would define newForeignPtr in terms of newForeignPtr_ and addForeignPtrFinalizer.) I'd prefer to avoid swapping the argument order because of code breakage. I think, we all agree on adding `newForeignPtr_' (so, I'll add that). The reason why I suggested reversing the argument order is that newForeignPtr_ :: Ptr a - IO (ForeignPtr a) and with *reversed* arguments also newForeignPtr myFinalizer :: Ptr a - IO (ForeignPtr a) 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. Manuel ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
