problems with FFI including h files

[Simon Marlow]

> > I thought we established that generating valid C prototypes from the
> > Haskell FFI type signature wasn't possible due to the incompleteness
> > of the Haskell type (lack of 'const' modifiers for one thing - is
> > there anything else?).
>=20
> Compilers use the same calling sequence whether you tell them about
> const or not. =20
>=20
> I believe that we can call all C functions correctly knowing only the
> calling convention (ccall, stdcall, etc) and the Haskell type.  I
> certainly hope this is true since Hugs' implementation of wrappers
> depends on it.

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.

The Haskell compiler can't generate a C prototype that can be used to
check for compatibility with any other C prototypes in scope, because
the Haskell FFI declaration doesn't contain all the necessary
information.  It has just enough information to be able to call the
function, nothing more.

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.

(look in the FFI mailing list archives, BTW - these issues were
discussed at length a while back).

Cheers,
	Simon