problems with FFI including h files

[Alastair Reid]

> Yes - but read the text I quoted before my message.  I'm not talking
> about calling the function, I'm talking about generating C
> prototypes.  You suggested that the Haskell compiler could generate
> prototypes and the C compiler could be used to check for mismatches,
> which would be great if it were possible, but sadly it's not.

Ah, it's the checking bit you were referring to.

I still think it's possible to perform some kind of basic sanity check
between header files specified in the ffi spec and the Haskell type
from the ffi spec though.  Maybe find a way to get gcc to tell you
that the arguments are passed as a 32bit int, a pointer and a single
precision float and check that against the code the ffi generates.
(gcc comes very close to telling you this kind of stuff if you play
around in the stabs information enough - though it might be easier to
modify gcc to just print it directly).

> The FFI *is* restricted to invoking functions, not macros (consider
> GHC's native code generator, for example). However, when compiling
> via C, we have to rely on prototypes being in scope from external
> header files, because of the above problem.

What I'm saying is that we could ignore the header files completely
and find some other method for checking the consistency of the ffi
code with the header files.

A