Fergus Henderson <fjh@cs.mu.oz.au> wrote,
On 03-Jan-2001, Alastair Reid <reid@cs.utah.edu> wrote:
I refrained from proposing this in an earlier mail, but I've been thinking about it for a long time. I *really* *really* want to be able to insert small snippets of foreign code into the source of a Haskell module.
I *really* *really* don't want this.
The current Hugs implementation of ffi could readily accomodate it because it generates a C file which you compile in the normal way but it would forever rule out an improved implementation (for use on especially well supported architectures) which doesn't need a compiler at all.
What would be the improvement? The fact that it doesn't need a C compiler?
If you don't have a C parser, you can't interface to C macros or enumeration constants, and you can't do type-safe cross-language interfacing. I don't see how that can be considered an improvement.
I also don't see how duplicating the C parser in a separate tool is an improvement either, especially considering that the separate tool will need to be updated to keep track of changes in C as it evolves.
You should consider that the situation fgor Mercury is slightly different from that for Haskell, as there is only one Mercury compiler. This makes merging tool support into the compiler infrastructure more attractive. If there is more than one compiler/interpreter for a language, duplicating a C parser in an external tool can prevent duplicating work in the various language implementations - which I prefer anytime, because Haskell implementations are very complex already anyway. So, IMHO, if a feature can be reasonably implemented in an extra tool, I'd rather do that than add it to the language core. I think, Marcin's inlining scheme demostrates that we can get the inlining even with an extra tool, so I don't see a compelling reason for making this part of the language. Cheers, Manuel