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 <[EMAIL PROTECTED]> 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 > [EMAIL PROTECTED] > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - [EMAIL PROTECTED] --------------------------------------------------------------------------- _______________________________________________ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users