> 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
_______________________________________________
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
