extended foreign decls

[Fergus Henderson]

On 04-Jan-2001, Manuel M. T. Chakravarty <chak at cse.unsw.edu.au> wrote:
> 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.

No, it's not a problem, it's a feature.

There's two choices:

	- completely disallow inter-language inlining
	  (inefficient all the time)

	- allow inter-language inlining in some cases
	  (efficient some of the time,
	   but inefficient at other times)

The ideal, i.e.

	- allow inter-language inlining in ALL cases
	  (efficient all of the time)

is not possible.  But that doesn't mean that we should therefore
choose to always completely disallow inter-language inlining.  Rather,
we should make it possible for implementations to offer that feature.

Not all implementations will take advantage of this possibility,
because there are trade-offs involved, and some implementations will
want to offer different trade-offs.  But that's OK. 
By allowing the possibility, we give programmers more choice.
Different choices will be better for different applications,
so giving the programmer the choice is a Good Thing.

> The decision is easier for you, because there is only one
> Mercury compiler.

There's only one front-end, but there's lots of back-ends.
Only two of them (less than half) compile via C.
But I want inline C to be fast in the one that compiles via C,
and I want inline Java to be fast in the Java back-end.

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