April 2002 - FFI - Haskell.org

Haskell FFI 1.0 vs Haskell/Direct: influence? loss of abstraction level?
by Hoehle, Joerg-Cyril 25 Apr '02

25 Apr '02

Hi, I've been busy with FFI design issues since 1995 (mostly Common Lisp). I was very impressed by the article "H/Direct: A Binary Foreign Language Interface for Haskell" (ICFP'98). It got me in touch with IDL. I'm quite surprised that the Haskell FFI 1.0 doesn't mention H/Direct or appears to take ideas from it. The H/Direct article says IIRC that it's the fruit of many years and iterations on FFI issues. I can confirm that by parallel experience in Lisp (OTOH, I can expand on low-level vs high-level FFI in a later email if you wish, esp. high-level failing to match some weird functions, but excellent 80-95% solutions). I very much appreciated the elegant declaration of many functions, especially the size_is() indication for the length of an array. It maps well onto many "pass buffer and length" functions, e.g. gethostname(), zlib:compress(). I'm disappointed that I do not find such an elegant approach reflected in the Haskell 98 Foreign Function Interface 1.0 (I read release Candidate 1). Therefore, I'd like to query the Haskell FFI mailing list for the reasons which may have lead to drop the very declarative approach of H/Direct in favour of the FFI 1.0, which to me, appears rather low-level (in contrast). To make things more concrete and to show the influence of H/Direct, here is what I dream of for the CLISP, an implementation of Common Lisp. Only is_size() (and :guard) are missing. :language, :[in-]out parameters, arbitrarily complex structure definitions, :alloca (vs :malloc-free), 0-terminated arrays (c-array-max & c-array-ptr) and the declarative style of definition have been in CLISP since 1995. (def-lib-call-out zlib-compress [eventually library] (:name "compress") (:arguments (dest (c-ptr (c-array uint8 is_size(destlen))) :out :alloca) (destlen ulong :in-out :alloca) (source (c-ptr (c-array uint8 is_size(sourcelen)))) (sourcelen ulong)) (:return-type int) ;; -- only dereference :out parameters when condition on return code is met: (:guard #'zerop) (:language :stdc)) Thanks for shedding light on this topic, Jörg Höhle. CLISP FFI documentation: http://clisp.cons.org/impnotes.html#dffi zlib: http://www.gzip.org/zlib/manual.html Feature Request: Searchable archives at haskell.org/pipermail :)

2 1

FFI Addendum, RC3 & Open Issues
by Manuel M. T. Chakravarty 24 Apr '02

24 Apr '02

I have put Release Candidate 3 up at http://www.cse.unsw.edu.au/~chak/haskell/ffi/ Changes wrt to the last version are the following: * 3.2: Clarified the description of foreign types; so far, `IO ()' was strictly speaking not included as a valid return type. * 4.1.5: New section discussing the traps & pitfalls of type promotion with C bindings. * 5.8: Clarified documentation for `MarshalAlloc.free'. * 5.8: Added `MarshalAlloc.realloc'. Moreover, I would like to draw your attention to the following points, which we should solve before I post the next version to %60haskell(a)haskell.org': * Olaf Chitil has pointed out some unclear points wrt to () and IO () as a result type in foreign declarations in the previous version of the Addendum. I have edited Section 3.2 to improve this, but you may want to check out that the new version meets your expectations. * I have added Section 4.1.5 as a consequence of the recent discussion on argument type promotion on this list. It seemed that everybody agreed what the FFI should do, but that a detailed explanation in the specification is needed, so I have added one. Please check whether you find it sufficient. * I think, for reasons of orthogonality `MarshalAlloc' should include realloc :: Storable b => Ptr a -> IO (Ptr b) I have added this in the document. Let me know if anybody disagrees with this. * There is the open question, raised by SPJ, of whether we like to have something like import_entity -> [String] export_entity -> [String] See my message from yesterday. * Sigbjorn, while adding support for OS threads to GHC, has introduced a new safety mode `threadsafe'. It seems worthwhile to include this into the Addendum. On systems that don't support OS threads, `threadsafe' might behave like `safe', but at least code that uses `threadsafe' would still be valid on other systems. The semantics is as follows: unsafe must not call back safe may call back; if it blocks outside Haskell, the whole Haskell system blocks threadsafe on systems supporting OS threads, the Haskell runtime will not block, even if the call blocks; must call an OS-thread safe procedure ('safe' remains the default.) If there are no objections, I will add the latter two changes to the FFI Addendum. Cheers, Manuel

2 2

ADV: Professional Internet Marketing
by Sydney Ferguson 12 Apr '02

12 Apr '02

1 0

testing without animation
by dave 11 Apr '02

11 Apr '02

1 0

FFI spec
by Simon Peyton-Jones 08 Apr '02

08 Apr '02

Manuel I've just had cause to look at the FFI spec. Here's an idea. Since we have two productions, one for foreign import and one for foreign export, let's separate the productions for "entity" into "import_entity" and "export_entity". That way we don't have to say "entity" in *both* 4.1 and 4.2. Would that be OK? If so, would you like to action it. This is for clarity only -- no change to semantics. Simon

2 1

Freeing arrays
by George Russell 08 Apr '02

08 Apr '02

Sorry if this has been raised before, I don't really follow this list. According to section 5.8 of the spec, MarshalAlloc.free will "free a block of memory that was allocated with malloc or mallocBytes". Fine. But will it also free blocks of memory allocated by MarshalArray.mallocArray and friends? Come to think of it, what about MarshalArray.reallocBytes? Also, what is the "realloc" function mentioned in the specification of reallocArray, or do you mean reallocBytes?

2 1