On Wed, 2007-12-19 at 19:07 -0800, Don Stewart wrote:

There are three approaches, depending on the size of your project.

Write your ow FFI decls manually.

- Good when you have a small job - and the C types are simple - example: strlen

Use hsc2hs:

- good for more complex C code. Scales nicely. But a bit tedious. - examples: pcre.h X11.h

Use c2hs:

- more automated than hsc2hs - less common

The latest version is available on hackage :-)

- scriptable - examples: gtk2hs

I use hsc2hs mostly.

The main advantage of c2hs over hsc2hs is that c2hs generates the correct Haskell types of foreign imports by looking at the C types in the header file. This guarantees cross language type safety for function calls. It also eliminates the need to write foreign imports directly which saves a lot of code. hsc2hs provides no help for writing function imports. The main disadvantage of c2hs compared to hsc2hs is that c2hs's support for marshaling structures is less than stellar while hsc2hs is pretty good at that. In gtk2hs we use both. We use c2hs for all function calls and we use hsc2hs to help us write Storable instances for a few structures. Both are supported by Cabal. Duncan

On Fri, 2007-12-21 at 10:25 +0100, Gour wrote:

On Thu, 20 Dec 2007 03:41:21 +0000 Duncan Coutts wrote:

...

In gtk2hs we use both. We use c2hs for all function calls and we use hsc2hs to help us write Storable instances for a few structures.

It looks that c2hs does more than hsc2hs and misses less than hsc2hs.

Why not equip c2hs to do the rest and have one complete tool instead of the two uncomplete ones? (I understand that time-factor could be the reason.)

The reason hsc2hs does the structure bits well is because it asks the C compiler about the sizes and offsets of field members. This means it is always accurate. For c2hs to do the same it has to calculate the sizes, offsets and alignments of types itself and it requires a lot of work and testing to make sure this is always 100% accurate. Duncan