> > * Marshaling pure sum types and pure product types, both
> are quite
> > common in APIs, is easy with GreenCard and H/Direct
> but a little
> > bit clumsy with the current FFI. Using a mechanism outside the
> > language (i.e. those preprocessors) for such common
> tasks is not
> > nice, so something has to be done here.
>
> There is a big problem for common C APIs. APIs specify the interface
> for calling functions sufficiently precisely that it's possible to
> exactly express the binary calling convention of functions in Haskell
> (except typedefs for argument and result types) and call them
> even from
> the NCG. OTOH structs, enums, bit fields and macros are not specified
> in a way that allows using them without the C headers (neither the
> order nor the complete set of struct fields is usually specified).
>
> It means that FFI has to either cooperate with the C compiler and
> generate stubs for C when compiling to the native code, or process
> C headers. It implies either additional low-level FFI features or
> external tools. Information gained only from Haskell record and enum
> definitions will not be enough.
I like the idea of processing the C header files and generating appropriate
marshalling code in Haskell from the information therein, i.e. the approach
that H/Direct and Manuel's C->HS take. There's one fewer level of
indirection in the implementation, but we have to know all the rules the C
compiler uses in determining alignment and padding for a struct.
On the other hand, using the stub approach, where the Haskell compiler
generates C stubs to pass through the C compiler, is much more likely to
enable us to generate bindings to C++ interfaces, since the rules for laying
out a C++ class and invoking methods are an order of magnitude more complex
than those for laying out a struct. It'd surely be nice to be able to
generate C++ bindings too.
So I'm not committed one way or the other, just helping to summarise the
options. Are there any others?
Cheers,
Simon
