extended foreign decls
Manuel M. T. Chakravarty
chak at cse.unsw.edu.au
Wed Jan 3 19:39:35 EST 2001
Tyson Dowd <trd at cs.mu.OZ.AU> wrote,
> On 03-Jan-2001, Manuel M. T. Chakravarty <chak at cse.unsw.edu.au> wrote:
> > Fergus Henderson <fjh at cs.mu.oz.au> wrote,
> > > 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.
> > This has some problematic consequences:
> > * Code which replies on this inlining would require any
> > high-performance Haskell compiler to compile via C.
> No code should rely upon this inlining for correctness.
That wasn't my point - I guess, I should have been more
clear about this. Having a language feature whose efficient
implementation requires a compiler to compile, say, via C is
a problem if somebody decides tomorrow to implement a
Haskell compiler directly generating assembler code.
The decision is easier for you, because there is only one
More information about the FFI