headers
Steve Lihn | 20 Dec 04:01

FFI question -- was: New slogan for haskell.org

On Dec 11, 2007 11:16 PM, Don Stewart <dons <at> galois.com> wrote:
> >    2. It offers strong support for integration with other languages and tools
> >    (FFI? Is the support strong?)
>
>    2. The FFI in Haskell is perhaps the most powerful out there.
>       You can import C or export Haskell to C with a single line FFI decl.
>
Don,
I am a newbie on FFI, but have been interested in looking into it. If
I google on "haskell FFI", what I find is typically:
1. The official Haskell 98 FFI 1.0
2. The FFI preprocessor -- greencard on haskell.org, where several
other preprocessors are listed (in the Link section): HaskellDirect, C
to Haskell, hsc2hs (included in GHC distributions), QForeign, KDirect.

The FFI 1.0 API is certainly the most robust tool. However, the
existence of preprocessors seem to suggest (at least very enticing)
that the use of a preprocessor would make life easier.

But when I dig deeper, several of them have not had any release in
(more than) 3 years. The only exception seem to be "C to Haskell",
which is part of gtk2hs, and hsc2hs, being part of GHC. It immediately
becomes confusing which tool I should use if I were to work on a FFI
project... Can you shed some light on this?

Thanks, Steve
Permalink | Reply |
headers
Don Stewart | 20 Dec 04:07
Gravatar

Re: FFI question -- was: New slogan for haskell.org

stevelihn:
> On Dec 11, 2007 11:16 PM, Don Stewart <dons <at> galois.com> wrote:
> > >    2. It offers strong support for integration with other languages and tools
> > >    (FFI? Is the support strong?)
> >
> >    2. The FFI in Haskell is perhaps the most powerful out there.
> >       You can import C or export Haskell to C with a single line FFI decl.
> >
> Don,
> I am a newbie on FFI, but have been interested in looking into it. If
> I google on "haskell FFI", what I find is typically:
> 1. The official Haskell 98 FFI 1.0
> 2. The FFI preprocessor -- greencard on haskell.org, where several
> other preprocessors are listed (in the Link section): HaskellDirect, C
> to Haskell, hsc2hs (included in GHC distributions), QForeign, KDirect.

Right. Most of those are out of date.

> The FFI 1.0 API is certainly the most robust tool. However, the
> existence of preprocessors seem to suggest (at least very enticing)
> that the use of a preprocessor would make life easier.

Yes, that's the foundation.

> But when I dig deeper, several of them have not had any release in
> (more than) 3 years. The only exception seem to be "C to Haskell",
> which is part of gtk2hs, and hsc2hs, being part of GHC. It immediately
> becomes confusing which tool I should use if I were to work on a FFI
> project... Can you shed some light on this?
(Continue reading)

Permalink | Reply |
headers
Duncan Coutts | 20 Dec 04:41

Re: FFI question -- was: New slogan for haskell.org


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
>
(Continue reading)

Permalink | Reply |
headers
Gour | 21 Dec 10:25
X-Face

Re: FFI question -- was: New slogan for haskell.org

On Thu, 20 Dec 2007 03:41:21 +0000
Duncan Coutts <duncan.coutts <at> worc.ox.ac.uk> wrote:

> 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.

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.)

I am for the choice, but there are several library-areas (database
binding is one) in Haskell where we could (maybe) apply/strive for
"less is better" slogan ;)

Sincerely,
Gour
(Continue reading)

Permalink | Reply |
headers
Duncan Coutts | 29 Dec 18:59

Re: FFI question -- was: New slogan for haskell.org


On Fri, 2007-12-21 at 10:25 +0100, Gour wrote:
> On Thu, 20 Dec 2007 03:41:21 +0000
> Duncan Coutts <duncan.coutts <at> worc.ox.ac.uk> 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
Permalink | Reply |

Gmane