Fergus Henderson wrote:

...

[...] the Haskell FFI has sacrificed quality for easy of implementation. If this starts causing problems for users, I think the right solution is to raise the bar for implementations, not to lower it. [...]

I definitely support Fergus' point of view, GHC and Hugs really rushed head over heels towards a wrong direction, IMHO. If I see this correctly, the only problems were that GHC's native code generator doesn't handle macros currently and the handling of "broken" macros in the C back-end and Hugs. I think we can safely forget about the latter (by using #undef or a small wrapper), and we should have a look how to solve the former. Mercury seems to handle this, although I'm currently not sure at what price (in terms of implementation effort and possible performance loss).

Fergus, as usual, has a number of good points. I agree that a good FFI should target the C API rather than the ABI, tagetting the ABI is a compromise. The errno example isn't valid here: errno isn't a function, and it isn't guaranteed to be an addressable location either, so the FFI can't access it. There are some other good examples though: on Windows, lots of string functions have two variants, one with an 'A' suffix (ASCII) and one with a 'W' suffix (WIDE), and the plain function name without the suffix is #defined to one or the other based on the value of the UNICODE CPP symbol. The documentation only refers to the un-suffixed version, so in order to write Haskell FFI code that calls these functions you have to dig through the header files, or compile via C, or use a separate C stub. This is really annoying. It's one of those situations where doing The Right Thing hurts you in the pockets, and only fixes a small minority of problematic cases that could be worked around anyway. Worse is better, as they say :-P Cheers, Simon