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