May 2003 - FFI - Haskell.org

Example: Binding C++ to Haskell using the ffi
by David Sankel 13 Dec '03

13 Dec '03

Sorry, forgot attachment . . . again. :-P -- Here is some example code doing just that. It uses ghc. Questions: Can one think of better ways to interface generic c++ libraries to Haskell? What do you think of the ->> member function operator? for the ffi people: Has any though gone into cplusplus? If so, how would it interface? Would stubs on the c++ side be generated or would it use the code directly. Later, David J. Sankel

2 1

ANN: H98 FFI Addendum 1.0, Release Candidate 9
by Manuel M T Chakravarty 10 Jun '03

10 Jun '03

RC 9 of the FFI Addendum is now at http://www.cse.unsw.edu.au/~chak/haskell/ffi/ The addendum seems to be stable and I like to close Version 1.0. There is only one open question: What to do about "threadsafe"? In the threads discussion, there seemed to be a tendency to not distinguish between "threadsafe" and "safe" after all. Shall we remove "threadsafe" from 1.0? That's what I tend to and will do unless there are strong arguments to retain "threadsafe". Cheers, Manuel -=- Changes since RC 8 * 5.8: `MarshallAlloc.reallocBytes' is no longer permitted on memory allocated with `alloca' or `allocaBytes'. * 6.1: Deinitialisation of the RTS via `hs_exit()' followed by (re)initialisation with `hs_init()' must be supported.

5 12

RE: ANN: H98 FFI Addendum 1.0, Release Candidate 10
by Simon Marlow 04 Jun '03

04 Jun '03

> Manuel M T Chakravarty <chak(a)cse.unsw.edu.au> writes: > > > -=- Changes since RC 9 > > > > * 6.2: All the types in CTypes must be newtypes that are exported > > abstractly. > > This change makes things highly inconvenient in nhc98. A newtype > can only be passed across the FFI in nhc98 if we have enough > information to determine the original type that is being renamed. > If Foreign.C.Types exports them abstractly, then currently we do not > have that information, and so these types cannot be used at all! > > I am not suggesting that the newtype constructors should necessarily > be part of the API seen by the user, but the problem comes down to a > known deficiency in nhc98's interface file conventions. How about exporting them non-abstractly for nhc98 only, and adding a comment to explain why the workaround is necessary? Cheers, Simon

3 2

ANN: H98 FFI Addendum 1.0, Release Candidate 10
by Manuel M T Chakravarty 04 Jun '03

04 Jun '03

I have incorporated the feedback to RC 9 into RC 10, which you can get, as always, from http://www.cse.unsw.edu.au/~chak/haskell/ffi/ I also tracked the addition of `FinalizerPtr' in fptools. If there are no further suggestions, I will post RC 10 on the main list for final (hopefully!) review. Cheers, Manuel -=- Changes since RC 9 * 1: Mentioning interaction with foreign threads as an open problem. * 2 & 3: Removed `threadsafe' again, as the proposal for thread support is still evolving and it is not yet clear whether a new safety level is required. * 5.5: Added the type synonym `FinalizerPtr' and rewrite the documentation of finalizers. * 5.6: Clarified the description of `StablePtr' * 5.8: Added `finalizerFree' * 6.2: All the types in CTypes must be newtypes that are exported abstractly.

8 12

ffi@haskell.org
by sms 31 May '03

31 May '03

1 0

Allocation & Marshalling Question (again)
by Adrian Hey 30 May '03

30 May '03

Hello, Judging by the silence that greeted my last posts re this a couple of weeks ago I suspect this is of no interest to anyone but me :-( An extra couple of weeks cogitation on this hasn't really changed MHO much (other than I'm no longer so pessimistic about the safety of my <+ operator). Seeing as the FFI seems to be close to finalization I thought I'd have another go. So excuse me if this seems half baked, but am I the only one who thinks the type signatures of utilities like this.. allocaBytes :: Int -> (Ptr a -> IO b) -> IO b ..are rather inconvenient? Wouldn't.. allocaBytes :: Int -> (Ptr a -> b) -> b ..be more useful? To get around this I defined an operator.. infixl 0 <+ (<+) :: (Ptr a -> b) -> ((Ptr a -> IO b) -> IO b) -> b f <+ alloc = unsafePerformIO $ alloc $ \p -> return $ f p (Actually I now think the type of <+ should be.. (<+) :: (a -> b) -> ((a -> IO b) -> IO b) -> b ..so it will work with functions like withCStringLen) This seems to work, but I wasn't entirely comfortable with its safety due to the use of unsafePerformIO. Anyway, perhaps there's a good reason for things having been done this way, but right now I can't see it. So could somebody who understands the reasons for the FFI design decisions and underlying implementation explain why a change such as I have suggested could not or should not be made? Possible explanations that occur to me are.. 1- It's technically impossible. 2- It's unnecessary because FFI users can define their own contraptions like <+ if they want them, assuming the use of unsafePerformIO in this context really is safe (and unsafePerformIO is available). 3- It's undesirable because the existing forms are better in some way. 4- It's undesirable because it would break existing code (not true AFAICS). Thanks -- Adrian Hey

3 8

ffi@haskell.org
by sms 30 May '03

30 May '03

1 0

RE: Allocation & Marshalling Question (again)
by Simon Marlow 29 May '03

29 May '03

> On Wednesday 28 May 2003 10:32, Simon Marlow wrote: > > > Even in GHC where we use garbage collected memory instead > of malloc, we > > still make use of the IO monad to control the lifetime of > the allocated > > memory. > > Thanks for that info. I'm not to clear about what the > intended implementation > is (if there is one) from reading the FFI spec. It seems to > me that if the > IO monad is used to control the lifetime you could use stack > allocation quite > easily. (Dunno if that would be any more efficient for the > ghc rts though.) > Using the garbage collected heap but not actually using normal garbage > collection mechanisms seems a bit strange to me :-) I actually thought long and hard about how to implement allocaBytes efficiently in GHC, before eventually coming up with the current scheme. The problem with using stack allocation is that stacks move around in GHC, and you need stable storage for allocaBytes because it passes the pointer to a foreign call. You could use a separate, stable, stack, but then you also need to move the stack pointer back down at the end of the alloca, and that needs to be done in an exeception-safe way, which is also expensive. The current idea is to use a pinned, but garbage-collectable allocation. The pinned object is "touched" at the end of the alloca to ensure that it cannot be garbage collected until then. We don't need an exception handler: if an exception is raised in the middle of the alloca, then the pointer to the object will be simply dropped and the memory garbage collected. Cheers, Simon

1 0

RE: Allocation & Marshalling Question (again)
by Simon Marlow 29 May '03

29 May '03

> Judging by the silence that greeted my last posts re this a > couple of weeks > ago I suspect this is of no interest to anyone but me :-( > > An extra couple of weeks cogitation on this hasn't really > changed MHO much > (other than I'm no longer so pessimistic about the safety of > my <+ operator). > > Seeing as the FFI seems to be close to finalization I thought I'd have > another go. So excuse me if this seems half baked, but am I > the only one who > thinks the type signatures of utilities like this.. > allocaBytes :: Int -> (Ptr a -> IO b) -> IO b > ..are rather inconvenient? > > Wouldn't.. > allocaBytes :: Int -> (Ptr a -> b) -> b > ..be more useful? I haven't thought about this too hard, but it seems "technically difficult" if not "technically impossible". In an implementation which uses a foreign call to malloc to implement allocaBytes, then there has to be a reliable way to ensure that the memory is deallocated later. If we're not in the IO monad, then I can't see how to do this. Even in GHC where we use garbage collected memory instead of malloc, we still make use of the IO monad to control the lifetime of the allocated memory. Cheers, Simon

2 1

RE: H98 FFI Addendum 1.0, Release Candidate 10
by Simon Peyton-Jones 26 May '03

26 May '03

The bound-threads story interacts with the FFI -- indeed, it's in a document in Haskell-report/ffi/threads.tex. Do we ultimately plan to fold it into the FFI spec (but, awkwardly, it must speak of concurrency)? Or do we ultimately plan to have a separate "blessed appendix" on concurrency generally? And if the latter, who would like to edit it? Manuel has done a great job with the FFI spec; I doubt concurrency will be half as hard. Simon | -----Original Message----- | From: haskell-admin(a)haskell.org [mailto:haskell-admin@haskell.org] On Behalf Of Manuel M T | Chakravarty | Sent: 22 May 2003 22:33 | To: haskell(a)haskell.org | Subject: ANN: H98 FFI Addendum 1.0, Release Candidate 10 | | Dear Haskell Folks, | | Release Candidate 10 of the H98 FFI Addendum 1.0 is now | available from | | http://www.cse.unsw.edu.au/~chak/haskell/ffi/ | | The change log since RC 7, which was the last version | circulated via haskell(a)haskell.org, is appended below. | | Please review this specification carefully. If no | suggestion that leads to a serious change is made within two | weeks, I will freeze version 1.0. | | Thanks, | Manuel | | -=- | | Changes since RC9: | * 1: Mentioning interaction with foreign threads as an open problem. | * 2 & 3: Removed `threadsafe' again, as the proposal for thread support is | still evolving and it is not yet clear whether a new safety level | is required. | * 5.5: Added the type synonym `FinalizerPtr' and rewrite the documentation | of finalizers. | * 5.6: Clarified the description of `StablePtr' | * 5.8: Added `finalizerFree' | * 6.2: All the types in CTypes must be newtypes that are exported | abstractly. | | Changes since RC8: | * 5.8: `MarshallAlloc.reallocBytes' is no longer permitted on memory | allocated with `alloca' or `allocaBytes'. | * 6.1: Deinitialisation of the RTS via `hs_exit()' followed by | (re)initialisation with `hs_init()' must be supported. | | Changes since RC7: | * Clarified the lexis of C identifiers and C header file names | * In `ForeignPtr', added `mallocForeignPtrArray' and `mallocForeignPtrArray0' | * Clarified spec of allocations functions adding constraints taken from the | corresponding C routines | * `mallocBytes' and `allocaBytes' must align memory sufficiently for any | basic foreign type that fits into the allocated block | * Removed typos in the description of the module `ForeignPtr' | * Added Peter Gammie to the list of acknowledged people | * `addForeignPtrFinalizer' guarantees that finalizers for a single foreign | pointer are executed in the opposite order as they were added. | * `Storable': Require that the size is divisible by the alignment | * Added Ross Paterson to the list of acknowledged people | * Added hs_free_fun_ptr() and hs_free_stable_ptr() | * Changed order of arguments of `mkIOError' and `annotateIOError' to match | with the current implementation in GHC's FFI libraries. | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

2 1