- FFI - Haskell.org

RE: Typing f.e.d.
by Simon Peyton-Jones 14 Feb '01

14 Feb '01

This looks plausible to me too --- but I agree with Alastair that we should not remove support for Addr, including in f.e.d. Backward compatibility is a pain, but lack of is a fast way to lose customers. Simon | -----Original Message----- | From: Sven Panne [mailto:Sven.Panne@informatik.uni-muenchen.de] | Sent: 11 February 2001 16:01 | To: The Happy Bit Fiddlers | Subject: Typing f.e.d. | | | I have a small change request regarding foreign export dynamic. | Currently the FFI doc says: | | topdecl | : ... | .. | | 'foreign' 'export' [callconv] 'dynamic' varid :: | prim_type -> IO Addr | | GHC additionally allows: | | prim_type -> IO Ptr | | As usual the FFI "looks through" newtypes. But now that we have | FunPtr, the following typing makes much more sense: | | 'foreign' 'export' [callconv] 'dynamic' varid :: prim_type | -> IO (FunPtr prim_type) | | where both prim_types have to be the *same*. We should probably allow | the old Addr-typing as well for some time to facilitate the | transition, | but not the Ptr-typing (bleeding edge people will know what to do :-). | The corresponding changes to GHC look easy, so I'd like to commit this | if there are no objections. | | Furthermore, the FFI docs still talk about Addr only, not Ptr/FunPtr. | Now that Addr is deprecated, this should be changed, too. | | Cheers, | Sven | | _______________________________________________ | FFI mailing list | FFI(a)haskell.org | http://www.haskell.org/mailman/listinfo/ffi |

1 0

RE: Typing f.e.d.
by Simon Marlow 13 Feb '01

13 Feb '01

> What libraries is the evolving design being tried out on (I > know about your > OpenGL library). In GHC we have implementations of Directory, Time and CPUTime using the new FFI and hsc2hs. The new implementations should work on Hugs with only minor tweaks, given suitable implementations of the FFI libraries. I'm hoping at some point to write a portable implementation of IO using the new FFI. > 1) As a user, I only _have_ to use the low level ffi > libraries: Addr, Word, > Int64, ForeignObj, etc. Its nice if the high level > libraries are useful > too but not essential. > > 2) As an ffi implementer/maintainer, I only have to implement > the agreed > ffi interface and all the libraries on top will "just work". > > 3) They're not supposed to be standard so it's ok to > experiment with the > design a bit. The libraries *are* part of the standard. The FFI language extensions are just one part of the propsed FFI standard; the low and high-level marshalling libraries form the other part. Cheers, Simon

1 0

RE: Typing f.e.d.
by Simon Marlow 12 Feb '01

12 Feb '01

> As usual the FFI "looks through" newtypes. But now that we have > FunPtr, the following typing makes much more sense: > > 'foreign' 'export' [callconv] 'dynamic' varid :: prim_type > -> IO (FunPtr prim_type) > > where both prim_types have to be the *same*. We should probably allow > the old Addr-typing as well for some time to facilitate the > transition, > but not the Ptr-typing (bleeding edge people will know what to do :-). > The corresponding changes to GHC look easy, so I'd like to commit this > if there are no objections. Sounds reasonable to me. Simon

1 0

ANN: C->Haskell 0.8.1
by Manuel M. T. Chakravarty 11 Feb '01

11 Feb '01

I am pleased to announce the availability of version 0.8.1 of the interface generator C->Haskell. It works with the current stable release series 4.08.x of GHC as well as the current development series 4.11. For both versions of GHC, it supports the *same* FFI library that GHC natively only supports in the development version 4.11 and which constitutes the result of the work of the FFI Task Force over the last couple of months. The interface specification of the library is online available at http://www.cse.unsw.edu.au/~chak/haskell/c2hs/docu/c2hs-4.html For more information on C->Haskell and for downloading, see http://www.cse.unsw.edu.au/~chak/haskell/c2hs/ The main feature in this release is the new FFI library. It should allow users of the GHC stable series to use the new FFI library interface, which we hope to keep stable from now on. An update of the C->Haskell tool proper is being worked at. Happy Hacking, Manuel

1 0

RE: MarshalError
by Simon Marlow 08 Feb '01

08 Feb '01

> Sun, 04 Feb 2001 17:15:16 +1100, Manuel M. T. Chakravarty > <chak(a)cse.unsw.edu.au> pisze: > > > I am just wondering whether we would want to add the > > following to `MarshalError': > > Maybe throwIf should be changed to failIf? The same function would > work for both IO and Maybe. I don't see that. Presumably you mean overloading failIf with the Monad class, but `fail' takes a String and in the IO monad we want to raise a real IOError, not just a UserError. Cheers, Simon

4 3

MarshalError
by Manuel M. T. Chakravarty 04 Feb '01

04 Feb '01

I am just wondering whether we would want to add the following to `MarshalError': -- wrap the result into a `Maybe' type (EXPORTED) -- -- * the predicate determines when the result is considered to be non-existing, -- ie, it is represented by `Nothing' -- -- * the second argument allows to map a result wrapped into `Just' to some -- other domain -- nothingIf :: (a -> Bool) -> (a -> b) -> a -> Maybe b nothingIf p f x = if p x then Nothing else Just $ f x -- instance for special casing null pointers (EXPORTED) -- nothingIfNull :: (Ptr a -> b) -> Ptr a -> Maybe b nothingIfNull = nothingIf (== nullPtr) These are the `Maybe' counterparts of the exception routines in MarshalError. This style of using `Maybe' for handling special return values isn't covered by the `Maybe'-related routines in `MarshalUtils'. Cheers, Manuel

2 1

RE: Let's get this finished
by Simon Marlow 15 Jan '01

15 Jan '01

> On Mon, 15 Jan 2001, Simon Marlow wrote: > > > data UnsafeCString > > withUnsafeCString :: String -> (UnsafeCString -> IO a) -> IO a > > > > where an UnsafeCString is valid only in an argument position of an > > unsafe foreign import. > > Much of the conversion stuff would have to be done in a different way. > An additional internal interface to conversions implemented in C > (with ByteArrays instead of Ptrs), pointer arithmetic moved from > Haskell to C, and in future hard to mix with Handle I/O done on > Ptrs. Hmm. You're right, unfortunately :( This is depressing. > > I still can't think of a good way to do this in general. Perhaps > > enhancing the garbage collector so that it could "pin" objects - but > > you've still got the problem of keeping the lifetime of the > ByteArray > > in sync with the Ptr. > > Lifetime is not a problem: > withByteArray :: ByteArray -> (Ptr a -> IO b) -> IO b > > (And now we know that the ByteArray type should be parametrized!) Well, the reason I said this was a problem was because I was trying to avoid the overhead of the exception handler or continuation in withByteArray. Actually we can do this right now: you allocate a large ByteArray (>= 4k ish) to make sure it gets allocated in immovable space, and then use touch# to keep it alive. You get through a lot of memory this way, but it should be faster than malloc/free. I'll do some experiments. Cheers, Simon

1 0

RE: Let's get this finished
by Simon Marlow 15 Jan '01

15 Jan '01

> I am all for moving the old CString routines to > UnsafeCString, but that might annoy George and others who > still have code importing the old CString. > > The old code contains cruft like > > fill arr n [] = > _casm_ ``((PP_)%0)[%1] = NULL;'' arr n > fill arr n (x:xs) = do > barr <- packStringIO x > _casm_ ``((PP_)%0)[%1] = (P_)%2;'' arr n barr > fill arr (n+1) xs > > which doesn't make much sense keeping around with the new > FFI stuff in place. It doesn't even look like it works! If I'm reading the above code correctly, it seems to build a ByteArray in which each element is a pointer to another ByteArray, so if any of the arrays moves you're hosed. The Posix library uses it to implement exec. George, are you using it at all? Most uses of unpackCString and friends can be replaced with peekCString (CStrings from a foreign function are bound to be Ptr CChar). For packString, I've been using the following interface instead (in ghc/lib/std/PrelCString): data UnsafeCString withUnsafeCString :: String -> (UnsafeCString -> IO a) -> IO a where an UnsafeCString is valid only in an argument position of an unsafe foreign import. Would anyone object to adding these to CString? > As 4.08.2 will still have the old interfaces, one possible > route might be a more radical step for the first GHCi > release (which will break all kinds of things anyway, I am > sure :-} We could collect all the old interfaces (I guess, > there are other modules beside CString that can be phased > out) in a new module "LangDeprecated" where we maybe even > redefine the old routines in terms of the new ones. Code > using the old interfaces can, then, just import > LangDeprecated until the code gets revised, but it is clear > that the old interfaces will vanish one day. Sounds reasonable, but a lot of hassle to get right. I'm not in favour of hassle purely for the purposes of deprecated interfaces :) > Moreover, as soon as the unicode stuff gets in, all the old > C-style string handling will be wrong anyway. > > As for bytearrays: AFAIK the only reason for using byte > arrays over malloc is efficiency. So, that makes them, I > think, mainly interesting for allocating temporary storage, > which is maybe even more critical for routines that need > pointers to storage as out parameters to C routines doing > little work. This is actually more critical for routines > handling small data items like ints than for strings. So, > we would like to have something like > > with[Object]Unsafe :: Storable a => a -> (Ptr a -> IO b) -> IO b > withArrayUnsafe :: Storable a => [a] -> (Ptr a -> > IO b) -> IO b > withArray0Unsafe :: Storable a => a -> [a] -> (Ptr a -> > IO b) -> IO b > withCStringUnsafe :: String -> (CString -> IO a) -> IO a > withCStringLenUnsafe :: String -> (CStringLen -> IO a) -> IO a > > However, the real problem here is that if we want to use > `ByteArray' instead of `Ptr', the types have to change and > it is not H98 anymore. So, the problem is getting the > pointer from the allocation to the C function without moving > it. *sigh* I still can't think of a good way to do this in general. Perhaps enhancing the garbage collector so that it could "pin" objects - but you've still got the problem of keeping the lifetime of the ByteArray in sync with the Ptr. Cheers, Simon

3 2

qforeign-0.64 is out
by Marcin 'Qrczak' Kowalczyk 15 Jan '01

15 Jan '01

http://download.sourceforge.net/qforeign/qforeign-0.64.tar.gz * Adapted to FFI modules introduced in recent ghc-4-11. * For nhc98 its recent version from CVS is required, but it finally works. * hsc2hs processes # characters only outside comments and string literals, processing a file twice works (.hscc -> .hsc -> .hs), removed #option construct, added #enum construct, added -I, --include, and --version parameters, appropriate LINE pragmas are generated. * hsc2hs documentation is back. * Use one Makefile for all subdirs. (I've read <http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html>). * Check compiler abilities by compiling or running test programs instead of relying on its version. hsc2hs in ghc-4.11 is up to date. -- Marcin 'Qrczak' Kowalczyk

1 0

RE: Let's get this finished
by Simon Marlow 11 Jan '01

11 Jan '01

> Granted. And remember we already have a (quite ugly) module CString! > So here is a new proposal: > > * Deprecate the old definitions in CString and add > > type CString = Ptr CChar > mallocCString :: String -> IO CString > peekCString :: CString -> IO String > pokeCString :: CString -> String -> IO () > withCString :: String -> (CString -> IO a) -> IO a > newCString :: String -> IO CString > > * Add a new module CStringLen with > > type CStringLen = (CString, Int) > mallocCStringLen :: String -> IO CStringLen > peekCStringLen :: CStringLen -> IO String > pokeCStringLen :: CStringLen -> String -> IO () > withCStringLen :: String -> (CStringLen -> IO a) -> IO a > newCStringLen :: String -> IO CStringLen Ok. I'm still using the existing CString, but it can be renamed to something else. I've been using "UnsafeCString" since these ByteArray CStrings can only be passed to unsafe foreign functions. For now, let's just rename CString to UnsafeCString and change all the uses. Cheers, Simon

2 1