Generating Function Prototypes

Simon Marlow simonmar at
Mon Jul 8 05:14:00 EDT 2002

> I think this is a very misleading way to describe the problem.
> A major goal of the ffi is to provide a portable way of interfacing
> Haskell to C.  If we regard the header file as an optional extra which
> some compilers need and some don't, then we have failed in that goal.
> The effort of producing a header file is sufficient that ffi code
> supplied without them will be very hard to port to ghc -fvia-C (and,
> as I understand it, -fvia-C is considered the more stable platform
> especially when doing ffi work).

Sure, it's a problem, a bug in GHC, whatever.  But I don't see a way
around it!  We can't just generate prototypes because they might
conflict with prototypes already in scope.  Trying to guarantee that
there are *no* prototypes in scope seems too fragile - I can't imagine
requiring that everything in ghc/includes must not #include any system
headers or declare prototypes for anything outside the RTS.

Note that in most cases you already *have* a header file because you're
writing a binding for an existing C library, so the act of producing a
header file isn't that much of a chore.  Also you do get a small amount
of typechecking this way, whereas if we were somehow able to generate
prototypes then there would be no type checking at all.


More information about the FFI mailing list