Re: new ForeignPtr without finalizers
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. ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: new ForeignPtr without finalizers
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. -- Alastair Reid ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: new ForeignPtr without finalizers
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 () You're proposing a different name for newForeignPtr_? -- Alastair ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: new ForeignPtr without finalizers
Dean Herington [EMAIL PROTECTED] 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 ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
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
Re: new ForeignPtr without finalizers
On Monday 09 June 2003 4:59 am, Ashley Yakeley wrote:
OK, I just upgraded to GHC 6.0. How do I create a new ForeignPtr that
doesn't have any finalizers?
newSimpleForeignPtr :: Ptr a - IO (ForeignPtr a)
newSimpleForeignPtr ptr = ??
There is no direct way in the ffi. You could define a dummy function in C:
void dummy(HsPtr x) {}
and use:
newSimpleForeignPtr :: Ptr a - IO (ForeignPtr a)
newSimpleForeignPtr ptr = newForeignPtr ptr dummy
foreign import ccall dummy :: FinalizerPtr
It looks like you're using an idiom we didn't think of when designing the
library. Can you explain what you're trying to do and whether you think we
shoud provide direct support for newSimpleForeignPtr (which I'd be tempted to
call newForeignPtr_).
--
Alastair Reid
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
Re: new ForeignPtr without finalizers
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 ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: new ForeignPtr without finalizers
In article [EMAIL PROTECTED], Alastair Reid [EMAIL PROTECTED] wrote: It looks like you're using an idiom we didn't think of when designing the library. Can you explain what you're trying to do and whether you think we shoud provide direct support for newSimpleForeignPtr (which I'd be tempted to call newForeignPtr_). Specifically I want a ForeignPtr of a null Ptr that has no finalizers. I want a value of type ForeignPtr such that withForeignPtr will extract a null Ptr. My basic JNI ref type is newtype of a ForeignPtr. JNI gives me global references as Ptrs, and I wrap them in ForeignPtrs with a finalizer that tells the Java VM I'm finished with it. When I want to pass such a ref back to JNI, I simply call withForeignPtr to extract the underlying Ptr. But sometimes I want to create my own null references. Before GHC 6.0, I used to call (newForeignPtr nullPtr (return ())), and that would give me a ForeignPtr that would work with withForeignPtr to give a null Ptr. But now I can't. -- Ashley Yakeley, Seattle WA ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: new ForeignPtr without finalizers
In article [EMAIL PROTECTED], Malcolm Wallace [EMAIL PROTECTED] wrote: Why would you want to? A ForeignPtr without any finalizers is semantically just a Ptr, plain and simple. I need a pointer type for which some values have finalizers, and some don't. -- Ashley Yakeley, Seattle WA ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: new ForeignPtr without finalizers
On Mon, Jun 09, 2003 at 01:21:38PM +0100, Malcolm Wallace 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 Yes, please. I use this function quite extensively in gtk2hs. Thanks, Axel. ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: new ForeignPtr without finalizers
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
Re: new ForeignPtr without finalizers
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 ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: new ForeignPtr without finalizers
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 () -- Dean ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: new ForeignPtr without finalizers
In article [EMAIL PROTECTED], Alastair Reid [EMAIL PROTECTED] 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) I think the most FPish solution would be this: newForeignPtr :: Ptr a - IO (ForeignPtr a) addForeignPointerFinalizer :: ForeignPtr a - FinalizerPtr a - IO () That gives you an empty finalizers function and an add finalizers function, like [] and (:). I don't really care, actually, as long as I can obtain the same functionality. -- Ashley Yakeley, Seattle WA ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
