FFI

[Manuel M. T. Chakravarty]

Koen Claessen <koen@cs.chalmers.se> wrote,

> 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!
[..]
> 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

I agree completely - except that in C->Haskell (and also
hsc2hs) you do *not* have to write that extra layer.  Or to
be precise, you do it in one go.  This was one of the main
design goals in C->Haskell.

You may know that when I started on Gtk+HS, I used the same
approach as you (for similar reasons as you do).  After many
lines of code, I found that it works nice that way, but
there are a couple of things which when automated would save
quite same work.  So, I automated just these piece, the rest
is still just verbatim Haskell code doing the marshalling.

Cheers,
Manuel