Re: FFI

don't forget one very big pro for hsc2hs, which is that it comes with ghc so you can count on it working. I find it tricky to keep c2hs (and hence gtk+hs) working with the latest ghc. no doubt the situation is getting better, but it is still somewhat of a hassle. I tend to use hsc2hs for 'small' bindings of a few functions, or when i am writing both the c and haskell code, and c2hs to try and wrap premade c libraries. John On Mon, Jan 14, 2002 at 04:45:12PM +1100, Manuel M. T. Chakravarty wrote:

Dylan Thurston wrote,

...

On Sat, Jan 12, 2002 at 01:24:54PM +1100, Manuel M. T. Chakravarty wrote:

...

I think, there are five options:

* H/Direct (you mentioned that already) * GreenCard (ditto) * C->Haskell http://www.cse.unsw.edu.au/~chak/haskell/c2hs/ * hsc2hs (comes with GHC) * Plain FFI

And what are the pros and cons of each? Presumably you recommend C->Haskell, since you wrote it; what makes it better?

Since your are asking, here my shamelessly biased opinion ;-)

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. Moreover, GreenCard (with all due respect) is a bit of a legacy. The other three tools clearly benefited from the GreenCard experience, but after all they were developed, because the authors thought that they can improve on GreenCard. This leaves us with H/Direct, C->Haskell, and hsc2hs.

I chose the order of listing these three tools on purpose. It is not only the historical order, but enumerates them in order of decreasing complexity. H/Direct is clearly the most powerful of the three. It is an IDL compiler with the ability to process a combination of C header files and matching annotation files as a form of poor man's IDL, whereas C->Haskell and hsc2hs only have one goal: Simplify the development of Haskell bindings to C libraries.

I believe in the design philosophy of having a set of small tools that do just one job, but do it well. So, I prefer a specialised tool like C->Haskell and besides, when I initially developed C->Haskell, H/Direct couldn't handle C headers yet. As for a feature comparison, this is what comes to my mind:

H/Direct pros: - It can automatically marshal structures. In C->Haskell, you have to do some of this manually. Automating the process is on the todo list.

C->Haskell pros: - Given a header file, you write on file which contains the Haskell API and binding hooks that link the Haskell entities to C entities. With H/Direct, you need the annotation file plus usually a Haskell module that redresses the automatically generated interface to what you want to present to the user. - Marshalling is expressed using a marshalling library in plain Haskell, which means it is easy to write special code to handle weird cases.

Regarding hsc2hs, it's idea was to be even simpler than C->Haskell. In particular, it is independent of the used C compiler, whereas C->Haskell has to imitate part of what a C compiler does. However, this comes at the expense of IMHO rather messy quoting requirements. Moreover, there is the potential in C->Haskell to provide quite a bit more automation than it implements at the moment.

Cheers, Manuel

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

-- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john@repetae.net ---------------------------------------------------------------------------