SimonM:

I explained (in my previous message) that GHC needs header files and prototypes in order to generate correct foreign calls when compiling via C. This is, IMO, a GHC-specific issue and doesn't have anything to do with the FFI specification - although confusion could be avoided if the spec pointed out that some implementations might need access to header files/prototypes in order to compile the code.

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). One might argue that the whole area of ffi is rife with portability problems because the portability problems encountered when writing, compiling and linking C code leak into the ffi. That is true to some degree but: 1) We have tools like autoconf which help make the C side of things more tractable. 2) The task of transferring a few linker flags from one makefile to another is quite small compared with the task of writing a suitable header file. 3) If I have m Haskell compilers and n platforms, then I have m*n combinations to worry about if the ffi is not portable but only n combinations to worry about if the ffi is portable between compilers. -- Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/