FFI

[Koen Claessen]

Manuel M. T. Chakravarty wrote:

 | I don't think that it makes much sense coding on the
 | plain FFI unless there are reasons for avoiding an
 | extra tool or the binding is very small.

Just my $0.02:

I have used the plain FFI for larger projects. The initial
reason I did this because my version of H/Direct stopped
working after I switched to a newer GHC, and I did not feel
like trying to fix it (again), or install a new tool. So, I
was forced to use the plain FFI.

I found it delightfully simple!

To write a correct FFI instance, I think it is absolutely
important that you understand completely what is happening
under the hood. My experience with H/Direct is that too much
is happening, and the things going on are so subtle, so that
often I look at the generated code to look if it has done
the correct thing.

The amount of work involved was not so bad at all. Usually,
I find that a small set of ad+hoc combinators (custom
written wrappers) will help one out a lot.

I have this experience both with static C libraries I want
to link to (written and published by other people), and
dynamic libraries (being under development by myself).

Admittedly not as large as gtk+hs, but still reasonably
large.

One more note I like to make: Using H/Direct (and no doubt
any of the other tools as well), I find that one ends up
writing a wrapper module anyway, which gives the library in
question a more Haskell-like interface (types, function
names, order of arguments, extra polymorphism wrappers,
runST-like tricks, etc.) The amount of work involved
removing the extra (automatic) layer is about the same as
the amount of work trying to make the interface compatible
with the automatically generated stuff.

/Koen.