Extension to the FFI to allow macro expansions to be avoided

[Simon Marlow]

> 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