Possible runtime overhead of wrapping the IO monad?

[Duncan Coutts]

On Tue, 2006-03-28 at 01:37 +0100, Brian Hulley wrote:
> Hi Duncan -
> I just declared duma_vertex3f (in another module) by:
> 
>      foreign import ccall duma_vertex3f :: Float -> Float -> Float -> IO ()
> 
> I thought this means that the C function prototype must be:
> 
>      void duma_vertex3f(HsFloat, HsFloat, HsFloat);
> 
> so I don't understand why GHC (or any other Haskell compiler) would ever 
> need to see a C header file to generate the correct code. What info could be 
> in the header that is not already in the Haskell type?

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.

The warning you saw was coming from gcc as it compiled the C code
emitted by ghc.

So it's mostly as a sanity check but actually there is some information
in the C prototype that is not reflected in the Haskell type. For
example 'const'ness, which is why you might sometimes see warnings from
gcc about casting away the const attribute. More seriously there is the
single/double issue. In the absence of a prototype C will promote single
to double. If the function really was declared as single then using
double will probably cause a crash. There are probably other examples
where not using a C prototype can lead to trouble.

There are more probably details on this issue in the emails during the
FFI standardisation process.

Interestingly that particular issue is less of a problem when not
compiling via C since the Haskell type does provide enough information
for making a call using the standard system ABI. C's type sytem (such as
it is) has slightly more information in it than just the system ABI
needs (such as const).

Duncan