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.