[Better a late answer than none :-/ ] "Alastair Reid" <reid@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