Among other things, the FFI was one of the topics at the recent Haskell Implementor's Meeting. One specific issue that was discussed following a proposal for better Java support by SPJ and Erik Meijer was a change to foreign import/export declarations. For some languages (eg, Java) a simple function name is not sufficient to identify an external function/method (eg, because of overloading). So, it seems like a good idea to extend the string specifying the external function name to contain more information. This string should include all information that is necessary to identify the external entity uniquely. This has two consequences: (1) The interpretation of the string becomes dependent on the foreign language and (2) the optional specifier of a dll in the current proposal should be folded into this string. Re (1): We obviously need to identify the foreign language. This can be achieved by extending the ccall/stdcall keyword to generally specify the foreign language (eg, we might use "java"). After that change, I think, the keyword for C should be "c" rather than "ccall" (we are not writing "javacall" either). Not sure what a good alternative for stdcall would be...win? pascal? Re (2): In Java, we obviously want to use qualified names (like "java.lang.foo"), but in the case of dynamic libraries and C calls it is less clear what the syntax should look like. "gtk: gtk_new_window" to specify that the dynamic library "gtk" (on Unix that would happen by loading "libgtk.so") has to be loaded to call the function "gtk_new_window"? The latter raises two further issues: (a) When a compiler generating C code translates a module including C bindings, it should be given the name of the relevant header file, too. Generally, the name of the header and the dynamic library may be different. So, we must be able to specify two names. (b) Some of the language specific information (like the header file and the dynamic library) often is the same for all foreign declarations in a module. It is annoying to have to repeat it in every declaration and makes it more difficult to alter conditionally. Is it reasonable to require that only foreign declarations of a *single* foreign language are allowed per Haskell module? Would one single global declaration of the relevant information, then, be sufficient? And do we want to specify the foreign language used in this module in this global declaration, too? Summary of Open Points ~~~~~~~~~~~~~~~~~~~~~~ - Language specifiers: Other names for "ccall" (possibly, "c") and "stdcall". - Header files: Syntax for specifying a header in case of a foreign declaration for C. - Only one foreign language per Haskell module? - Global specification of parameters such as the foreign language, dynamic library to be loaded, and header file to be included? Opinions? Cheers, Manuel