Here is nhc98's approach to solving the problem. The usual case is for the Haskell compiler to generate a C prototype for the FFI function based solely on the Haskell type. On the rare occasions where the generated prototype conflicts with a #include'd prototype, you can add the 'noproto' modifier to the Haskell FFI decl, and the prototype is omitted. This is both easy, and (I would guess) very portable.
But surely that would be non-portable because different Haskell systems would have different prototypes in scope? Or am I not understanding the idea? Cheers, Simon
add the 'noproto' modifier to the Haskell FFI decl, and the prototype is omitted. This is both easy, and (I would guess) very portable.
But surely that would be non-portable because different Haskell systems would have different prototypes in scope? Or am I not understanding the idea?
The idea is that, on the whole, it doesn't matter whether (or how many) header files are included. By and large, the generated prototypes are compatible with any that might be in scope already. So yes, where there is a conflict due to a particular compiler bringing certain prototypes into scope (requiring 'noproto'), and another compiler would not have that prototype in scope, this is when portability of the source code is strained. However, I am arguing that this is a comparatively rare situation, and moreover that some simple #ifdef'ery could make up the difference between the compilers in that rare case. Regards, Malcolm
participants (2)
-
Malcolm Wallace -
Simon Marlow