Haskell FFI 1.0 vs Haskell/Direct: influence? loss of abstraction level?
reid at cs.utah.edu
Thu Apr 25 06:38:58 EDT 2002
> 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
> 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):
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,
More information about the FFI