On 04-Jan-2001, Manuel M. T. Chakravarty <chak@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@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.