Extension to the FFI to allow macro expansions to be avoided
fjh at cs.mu.oz.au
Wed Apr 14 14:23:05 EDT 2004
On 08-Apr-2004, Alastair Reid <alastair at reid-consulting-uk.ltd.uk> wrote:
> Now that I understand the problem, my feeling is that the problem is not with
> curses but with GHC's compilation method. GHC is using a shortcut by
> pretending that the ffi is for interfacing to cpp+C whereas the ffi is quite
> clear that it is for interfacing to C. So, I think the thing to do is fix
I think this is a mischaracterization of the problem.
Talking about "cpp+C" is a misnomer; the C preprocessor is a part of C,
and has been so since long before Haskell even existed.
The Haskell FFI is designed for interfacing with foreign languages at the
ABI level, rather than the API level. While I understand the reasons for
that decision, any interface with C which can only interface at the ABI
level rather than the C API level is a second-class C interface; 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.
GHC should be applauded for providing users with an interface at the
C API level, and we should encourage other Haskell implementations to do
the same, even if this goes above and beyond the requirements standardized
in the Haskell FFI report.
Fergus Henderson | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
More information about the FFI