extended foreign decls

[malcolm-ffi at cs.york.ac.uk]

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