Simon Marlow <[EMAIL PROTECTED]> wrote,
> > > * 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.
I think, Haskell compilers are already complex enough and
one of the best features of the current FFI is that it is
simple. Especially, burdening the compiler with issues that
require different code generation depending on which
language we are interfacing to would be an absolute overkill
IMHO.
Cheers,
Manuel
