I can appreciate Alastair's reluctance to make changes to the FFI specification at this late stage. I would suggest that the rest of us really want it to stay stable and solid too. But at the recent implementers' meeting in Cambridge, it emerged that the current design has one or two very small flaws. So, because Alastair wasn't at that meeting where we discussed the possibility of some small changes, I thought it might be useful to rehearse some of the motivation here on the list. First, Simon PJ and Erik Meijer have been thinking about whether the current FFI story works adequately with Java as the foreign language rather than C. (Ghc now has a backend that compiles to Java rather than C or native code, so it makes sense to try to use foreign Java code directly.) The good news is that the FFI mostly goes through ok. The only points where they need to extend the mechanism are: foreign import [ccall|stdcall] "linklib" "foreignname" hname :: type * Neither of the calling conventions 'ccall' or 'stdcall' are appropriate for Java, so they suggested adding 'java' to the allowable set. (This raises the prospect of continually having to add new calling convention specifiers every time some compiler implementer gets a brainstorm for a new backend target language.) * The "foreignname" specification cannot be just the name of the function/method in Java. For one thing in Java, the same name can refer to lots of different methods distinguished by number and types of arguments. For another, Java uses namespaces. So the foreignname specifier ends up looking something like foreign import java "int Foo.Bar.g(bool)" g :: Bool -> IO Int But you will notice that this string encapsulates some of the information that was originally supposed to be in the "linklib" part of the specifier - namely "Foo.Bar". * The obvious corollary is that in fact a single string would be sufficient to specify both the "linklib" and "foreignname" specifiers in C as well. Indeed, for an arbitrary foreign language, all you need is to define the format of a single string, and the compiler implements a mini-parser to extract the information it needs (header / link-library / function name / namespace / whatever). Ok, so at this point we discussed what is currently used in the existing C foreign interface. It turns out that the current two-string specifier of "linklib" and "foreignname" is not the whole story. Sometimes (e.g. when compiling via C rather than native code) a compiler needs a prototype for the foreign function. Nhc98 simply generates a plausible prototype based on the Haskell type, but this is wrong in general because the compiler cannot always correctly guess the actual C prototype. For this reason, nhc98 has a non-standard hack foreign import noproto "foreignname" f :: type to fix those situations where it gets it wrong. Ghc on the other hand never tries to generate a prototype, but this means it needs its own non-standard hack, the compilation flag -#include <header.h> to get the correct prototype in almost all cases. Thus it seems that when the FFI is targetted at C, it actually needs three strings, not just two, for instance: foreign import "<header.h>" "linklib" "foreignname" f :: type So now we come back to the idea that a single string is actually sufficient, provided we know how to parse it for the foreign language in question. We played a little bit with deciding how to format the string for C, for instance: foreign import "<header.h>/linklib/foreignname" f :: type but the objection was raised that in a binding to a foreign library, a large part of the string would be identical in all the specifiers. Hence, finally, the proposal was that perhaps a single decl foreign decl [c|stdcall|java|...] "<header.h> / linklib.dll" could abstract all this information to a single place in the source file. (Note, we didn't even talk at the meeting about the possible syntax of such a decl - we have only started to discuss possibilities now on this list.) Does that help to motivate the current discussion a bit more Alastair? Regards, Malcolm