Haskell FFI 1.0 vs Haskell/Direct: influence? loss of abstraction level?
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 :)
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).
We wanted something that: - Was simple enough that Haskell implementers could all agree on what needed to be added to the compiler. - You could build HDirect on top of. Rather than standardizing HDirect, we chose to standardize the primitive operations on which HDirect is built. - You could build other FFI systems on top of. I think we have 5 different FFIs (built on the simple one) at the moment (raw ffi (plus extensive libraries), c2hs, hdirect, greencard and <one other>) all with different strengths and weaknesses. - Was useful by itself - making quick little jobs and bootstrapping easy.
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.
The way I imagine you implementing this and making it portable across implementations is that you and fellow implementers provide one or more low level interfaces for making calls, allocating/ reading/ writing memory in various ways, etc. and then you build a portable high level library on top of this - where the code in that library is shared across implementations. That's what we've done. The extensive libraries I hinted at above are documented here (sadly with very few examples of common use): http://www.haskell.org/ghc/docs/latest/set/sec-foreign.html When we don't use one of the frontends (hdirect, c2hs, etc), the code we write has roughly the same flavour as your example (except we use Haskell overloading and higher order functions instead of macros, macros and macros :-)
Feature Request: Searchable archives at haskell.org/pipermail :)
That would be nice, wouldn't it. (Hmmm, I think you can tell google to restrict its search to a particular site - so maybe we could just use google.) Hope this helps, -- Alastair Reid
participants (2)
-
Alastair Reid -
Hoehle, Joerg-Cyril