extended foreign decls

Manuel M. T. Chakravarty chak at cse.unsw.edu.au
Wed Jan 3 19:33:14 EST 2001

Fergus Henderson <fjh at cs.mu.oz.au> wrote,

> 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.

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.


More information about the FFI mailing list