Duncan Coutts wrote:
Because ghc does compile via C and does use the C header files to get the C function prototype. Well it can compile via C and it's recommended when compiling FFI code since it allows the Haskell type you've declared to be checked against the C prototype. [snip] There are more probably details on this issue in the emails during the FFI standardisation process.
I've found a thread at http://www.haskell.org//pipermail/ffi/2002-July/000554.html where someone else asked the same question, but apart from the problem of 'const' , and the desire to verify the actual type of the C function, I can't find any convincing case for requiring a header. Arg promotion would be solved if GHC just generated a prototype based on the Haskell type, and an explicit const_cast could be added by the writer of the C API when necessary. As for calling conventions, the FFI already specifies them (ccall versus stdcall etc). Even when I do specify a header, I still get the "warning: implicit declaration of function" message when my FFI functions are called from a different module, even when I use -#include "Duma.h" on the command line: C:\ghc\ghc-6.4\bin\ghc.exe -fglasgow-exts -fffi --make main.hs -ddump-simpl -O2 -#include Duma.h -optl-mwindows -optl-lDuma -optl-L"c:\dll" (Why does GHC not automatically #include the relevant header given by the foreign import decl at each call site?) Is there any solution to this problem? Thanks, Brian.