I'm still with Fergus on this one:
OK, so this is a hybrid approach -- most of the work is done by an external tool, but ghc still needs to know to #include the right .h file in the .hc file. So you don't need `foreign_code', but you still need `foreign_decls' or equivalent.
Exactly. Ghc has "foreign decl" by stealth. Hugs, nhc98, and hbc have no equivalent to #include an arbitrary .h file into generated-via-C code. I think we need a standard common language-based mechanism.
Personally I'd rather have a single well-designed convenient foreign language interface as a standard part of the language, rather than having a minimalistic foreign language interface in the language standard and having convenience provided by a separate tool (or by several competing separate tools). But I understand why you might differ on that point.
Indeed, this was one of the major initial motivations to develop a common FFI standard. People had plenty of FFI tools already, but the more tools we have, the more we need a standard language base for the tools to work with. Although I am happy to use tools for generating FFI code, I do *not* want to be *required* to use them to achieve simple functionality. I am about to add something like {-# CCODE #include <stdio.h> #-} to nhc98 as a stop-gap. Yes, this inevitably differs from whatever mechanism ghc currently uses. So yes, tools like hsc2hs will have to know which compiler they are generating for. Unless anyone wants to have a rethink now? :-) Regards, Malcolm