It's been quite some time since there was real activity on this list,
but this does not mean that there's nothing left to do in the FFI area
or people have lost interest in this topic. The FFI list was slowly, but
continually growing and has reached about 20 people by now, so I think
it's the right time to summarize the open FFI topics:
* Some performance tuning in GHC's implementation has to be done,
e.g. for peek/poke/fromIntegral on the sized integral types, but
this is a GHC topic, not a general FFI related one.
* Smoothen the differences of the Haskell implementations. I think
that the low-level aspects of the FFI (foreign import/export/label
and the libs imported by Foreign) are now stable enough to be
integrated into all non-GHC systems.
* Nuke lots of GHC-specific parts in hslibs in favour of the FFI,
e.g. remove all _casm_/_ccall_s. Hslibs should really be more
system independent.
* Currently you can't match a given C signature exactly on the
Haskell side, e.g. const modifiers etc. There have been some
experiments and proposals in this area, but AFAIK none of them
solved this problem in a smooth way.
* Marshaling pure sum types and pure product types, both are quite
common in APIs, is easy with GreenCard and H/Direct but a little
bit clumsy with the current FFI. Using a mechanism outside the
language (i.e. those preprocessors) for such common tasks is not
nice, so something has to be done here. IMHO generic programming
could probably help here, so instead of proposing some ad hoc
FFI-only solution, my question to the different Haskell
implementors is: What are the plans of integrating something in the
spirit of "Derivable Type classes" paper into their respective
systems? Being able to simply say `deriving (ForeignArgument)'
would be cool. :-)
* A higher-level marshaling library is urgently needed. There has
been some activity in this area recently, but the current state of
affairs is a little bit unclear to me: What kind of marshaling
problems are solved from a *user* perspective, not from an
implementor's perspective? Is it really necessary to use a plethora
of non-H98 features? And even if it really is, does the user of the
lib has to know about them or are they implementation details? We
should keep in mind that average people using the FFI are far more
likely to know the POSIX standard by heart than the Curry-Howard
isomorphism, dependent types, etc. This is not meant as a criticism
of the ongoing activities, only as a reminder that there are
consideration to be made, e.g. I fear that with every esoteric
feature of the type system involved we lose a bunch of potential
users.
Probably this list is by no means complete, so feel free to add *your*
wishes and/or comments. A good design doesn't emerge from scratch, only
by lots of experience and discussion.
Cheers,
Sven
