extended foreign decls

[Tyson Dowd]

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.

AFAIK none of it does.  One of our backends that compiled via C had this
sort of inlining turned off for quite some time.

> * As I understand, these pragmas are supposed to support not
>   only C.  How about C++ code?  Will there be a C++ backend
>   for Mercury just to make this code efficient?

No.  There's only (at most) one language per backend that can be inlined
in this way.  Otherwise you have to do your best.  You can inline the C
wrapper code that is used to call into C++, but that's about it.

The inlining is not important for semantics, but it might be important
for benchmarks ;-)

-- 
       Tyson Dowd           # 
                            #  Surreal humour isn't everyone's cup of fur.
     trd at cs.mu.oz.au        # 
http://www.cs.mu.oz.au/~trd #