Possible runtime overhead of wrapping the IO monad?

[Brian Hulley]

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.