Modification to foreign import/export

[Manuel M. T. Chakravarty]

[Better a late answer than none :-/ ]

"Alastair Reid" <reid at cs.utah.edu> wrote,

> > This has the advantage that when the library name is #ifdefed, the
> > conditional needs not to be repeated for each function. Similarly
> > for #included header names.
> 
> Note that this can be done without separating the library name from the ffi
> decl:
> 
> #ifdef UNIX
> # define LIBNAME "foo.so"
> #else
> # define LIBNAME "foo.dll"
> #endif
> 
> foreign import ... LIBNAME ...
> foreign import ... LIBNAME ...
> foreign import ... LIBNAME ...

That's not a solution, because cpp is not part of Haskell.
I think, it is a good idea to make things cpp-friendly where
we can, but we must not rely on cpp to solve any problem.

> I think I missed the motivation for extending the ffi to
> support other languages. 

We believe that by making the existing design a little bit
more modular and general, we can add the potential for
adding new languages at will without affecting any existing
part of the definition.  So, we want to move from a closed
C-sepcific design to an open and extensible one.  In the
process, we want to get rid of some current weakness (like
the issue of specifying headers), too.  That doesn't means
Hugs has to support any Java stuff (if this is what you are
worrying about).  In fact, it is entirely possible (as you
propose) to have a tool that rewrites a Java binding to a
JNI-binding going via C.

In a related point.  I agree that we have to keep backwards
compatibility in the implementations for a while, but the
whole FFI design was always experimental, which means that
it changes a couple of times until it is settled down.  I
have lots of code that I have to rewrite because of this,
too.

We are pretty happy with the libraries now.  There remains
some tweaking with the declarations, and then, the plan is
to write the definitive FFI definition and get it "approved"
by the community and that's it.  Then, we treat it like H98,
a fixed standard that has to be supported.

Cheers,
Manuel