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...] -- Alastair

On Monday 09 June 2003 3:48 pm, Manuel M T Chakravarty wrote:

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'.

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) Adopting the C idiom seems inappropriate (should use a Haskell idiom for Haskell code) and sets a bad example. Using higher order functions has the problem that the type becomes so general that you don't know what you're meant to pass in and certainly can't guess that there are only two choices and, despite the hype, function arguments are 2nd class citizens in Haskell (since you can't print them, compare them, etc.)

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. -- Alastair Reid

Dean Herington <heringto@cs.unc.edu> 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

Alastair Reid <alastair@reid-consulting-uk.ltd.uk> 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

On Thu, 12 Jun 2003, Alastair Reid wrote:

Manuel:

...

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.

Having written some more ffi code over the last couple of days, I agree that this is much more natural so, even though it will break all the packages I released in the last week, I now vote for swapping the argument order.

Since this breaks code anyway, we could adopt Dean's proposal to allow lists of arguments to newFP and addFPFinalizers without making things worse. I don't think we should do this though since I believe they would always be used with singleton or empty arguments and because the list-based versions can be trivially added with a foldM if they prove useful.

Actually, I think I prefer Ashley's idea of separating the creation of a ForeignPtr from the addition of a FinalizerPtr. So how about: newForeignPtr :: Ptr a -> IO (ForeignPtr a) addForeignPtrFinalizer :: FinalizerPtr a -> ForeignPtr a -> IO () newForeignPtrWithFinalizer :: FinalizerPtr a -> Ptr a -> IO (ForeignPtr a) newForeignPtrWithFinalizer f p = do p' <- newForeignPtr p addForeignPtrFinalizer f p' return p' Dean

Dean Herington <heringto@cs.unc.edu> wrote,

On Thu, 12 Jun 2003, Alastair Reid wrote:

...

Manuel:

...

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.

Having written some more ffi code over the last couple of days, I agree that this is much more natural so, even though it will break all the packages I released in the last week, I now vote for swapping the argument order.

Since this breaks code anyway, we could adopt Dean's proposal to allow lists of arguments to newFP and addFPFinalizers without making things worse. I don't think we should do this though since I believe they would always be used with singleton or empty arguments and because the list-based versions can be trivially added with a foldM if they prove useful.

Actually, I think I prefer Ashley's idea of separating the creation of a ForeignPtr from the addition of a FinalizerPtr. So how about:

newForeignPtr :: Ptr a -> IO (ForeignPtr a) addForeignPtrFinalizer :: FinalizerPtr a -> ForeignPtr a -> IO ()

newForeignPtrWithFinalizer :: FinalizerPtr a -> Ptr a -> IO (ForeignPtr a) newForeignPtrWithFinalizer f p = do p' <- newForeignPtr p addForeignPtrFinalizer f p' return p'

This is what is in RC 11, just with other function names. Manuel

Manuel M T Chakravarty wrote:

[ newForeignPtr / addForeignPtrFinalizer argument order ] This is the last outstanding issue. Shall we swap? I am torn. The swapped argument order seems more appropriate, but it will break code. Shall we have one more breakage before it's all frozen?

I think that FFI API breakage is effectively a non-issue: Try some non-trivial FFI code which is older than a few months and you'll either abandon portability or use #ifdefs. :-[ So I vote for swapping, too. (Note that GreenCard has to be changed, too, in case we agree on this.) Cheers, S.

Ashley Yakeley <ashley@semantic.org> 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 Regards, Malcolm