extended foreign decls

[Manuel M. T. Chakravarty]

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

> On 02-Jan-2001, Manuel M. T. Chakravarty <chak at cse.unsw.edu.au> wrote:
> > [This comment is a bit late, I know...]
> > 
> > malcolm-ffi at cs.york.ac.uk wrote,
> > 
> > > Fergus writes, triggered by my suggestion of "foreign value":
> > > 
> > > > Mercury supports this using `foreign_decls' and `foreign_code' pragmas.
> > > 
> > > 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.
> > > 
> > > GreenCard allows you to do this, via the %- or %C directives.  It is
> > > one of the features I miss most about the new FFI.  I know that it
> > > is always possible to write a small .c file and compile and link it
> > > in separately, but with the new FFI that now seems to necessitate
> > > writing an additional .h file as well.  And all for a handful of lines
> > > of foreign code that could easily be kept in the Haskell source, with
> > > the ease-of-comprehension benefits entailed by keeping everything
> > > together that belongs together.
> > [..]
> > 
> > I believe that functionality like this should be implemented
> > by an extra tool rather than the Haskell compiler.
> 
> Doing it in a separate tool will lose efficiency in some important
> cases.  If the compiler is compiling via C, then it can insert
> inline C code directly in the generated code, and thus get
> inlining.  But I think a separate tool would have to put the C code in
> a separate C file, which would prevent inlining.

This has some problematic consequences:

* Code which replies on this inlining would require any
  high-performance Haskell compiler to compile via C.

* As I understand, these pragmas are supposed to support not
  only C.  How about C++ code?  Will there be a C++ backend
  for Mercury just to make this code efficient?

Cheers,
Manuel