extended foreign decls

[Manuel M. T. Chakravarty]

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
Mercury compiler.

Cheers,
Manuel