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