Haskell FFI 1.0 vs Haskell/Direct: influence? loss of abstraction level?

[Alastair Reid]

> 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