Possible runtime overhead of wrapping the IO monad?

[Simon Marlow]

Brian Hulley wrote:

> 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).

The reason that GHC doesn't generate the prototype is because it might 
clash with an existing prototype from a header.  GHC doesn't know enough 
information (eg. const) to generate a correct prototype that won't clash.

> 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"

I don't know.  Try generating the .hc file and check whether it contains 
the correct #include?

> (Why does GHC not automatically #include the relevant header given by 
> the foreign import decl at each call site?)

No good reason, but we'd have to pass that information in the interface 
along with the unfolding of the foreign call, which we don't right now.

Cheers,
	Simon