Generating Function Prototypes

[Simon Marlow]

> 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.

Cheers,
	Simon