extended foreign decls

On 03-Jan-2001, Alastair Reid <reid at 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 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.