extended foreign decls
fjh at cs.mu.oz.au
Wed Jan 3 05:44:03 EST 2001
On 02-Jan-2001, Marcin 'Qrczak' Kowalczyk <qrczak at knm.org.pl> wrote:
> Tue, 2 Jan 2001 22:28:02 +1100, Fergus Henderson <fjh at cs.mu.oz.au> pisze:
> > Doing it in a separate tool will lose efficiency in some important
> > cases. If the compiler is compiling via C, then it can insert
> > inline C code directly in the generated code, and thus get
> > inlining. But I think a separate tool would have to put the C code in
> > a separate C file, which would prevent inlining.
> hsc2hs creates a .c file and a .h file for snippets of C code.
> The .h file is included into the .hc file generated by ghc.
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.
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.
Fergus Henderson <fjh at cs.mu.oz.au> | "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