extended foreign decls

[Fergus Henderson]

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.