On 04-Jan-2001, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> | "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.
_______________________________________________
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
