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. For cases where someone wants to write inline code in C or <insert language here>, they will need a compiler for that language. This is true regardless of whether they write the foreign code inline in the Haskell file or in a separate file. And it's easy enough to implement the other FFI constructs that don't involve inline foreign code in such a way that if you don't use inline foreign code, you don't need a foreign language compiler. -- 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.