extended foreign decls

Fergus Henderson 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 mailing list