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
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.
Here is nhc98's approach to solving the problem. The usual case is for the Haskell compiler to generate a C prototype for the FFI function based solely on the Haskell type. On the rare occasions where the generated prototype conflicts with a #include'd prototype, you can add the 'noproto' modifier to the Haskell FFI decl, and the prototype is omitted. This is both easy, and (I would guess) very portable. Here's a real example from the nhc98 implementation of the standard libraries: foreign import noproto rename :: CString -> CString -> IO Int The 'noproto' is needed because <stdio.h> has extern int rename (__const char *__old, __const char *__new) __THROW; (at least on Linux). In fact, out of ~300 foreign imports in the nhc98 libraries, this is the *only* occurrence of 'noproto', showing that this really is a rare case. Hence, generating prototypes by default in the -fvia-C route could be a serious proposition. Regards, Malcolm