A few comments on this FFI spec: * `foreign label' is missing, but that has already been pointed out. But I'm not sure how this should interact with the different calling conventions, e.g. what should the address of a Java method mean? * I'm not very happy with the fact that static/dynamic are only viewed as modifiers, like unsafe/safe. They almost completely change the meaning of a foreign declaration, including the typing rules. In my view, we have *5* different language constructs: `foreign import', `foreign import dynamic', `foreign export', `foreign export dynamic', and `foreign label'. GC-/concurrency-related modifiers or calling conventions on the other hand do not change the basic meaning of a foreign declaration. * Because of the reason stated above, I think static/dynamic *must* come first after import/export, but the order of unsafe/safe, callconv, and extent should not matter. The var (*not* varid, it was a design flaw IMHO) must be the last thing before the colon, otherwise it tends to drown in the syntax. Another possibility would be a rather strict order on the syntactic entities, but that's not of paramount importance. * Will the calling convention have influence on the typing of a foreign declaration? ccall vs. wincall obviously doesn't, but I'm not sure about the other conventions. I haven't thought very deeply about this yet, but this would be an unfortunate situation. * Some care should be taken to be backwards compatible with the existing FFI, e.g. a plain foreign import sin :: Double -> Double should still be valid, at least for a transition time, and should mean the same thing as foreign import ccall safe static "sin" sin :: Double -> Double in Manuel's syntax, probably yielding a deprecation warning. * IIRC we concluded some time ago that it's not feasible to mirror all strange typing phenomena on the foreign side in the Haskell type, e.g. const modifiers, arrays vs. pointers to elements, etc. But I can't find anything in this proposal to specify these things, e.g. in the extent or something else. * What about automatic prototype generation for ccall/wincall functions? Even if don't require such a thing, this problems related to this topic should be mentioned somewhere. * I don't understand the last part of section 3.2.1, mentioning the loading of dynamically loaded libs. Is something like dlopen() meant here or linking against a libfoo.so? And the details of how/when this linking should be done are completely obscure to me. * How will we differentiate between virtual vs. non-virtual methods in the cplusplus calling convention? What about class methods vs. instance methods? Will these distinctions have influence on the typing rules? If yes, coding this into the extent would be wrong. * The JVM has *4* different instructions for method invocation (invokeinterface, invokespecial, invokestatic, and invokevirtual), so our static/dynamic distinction seems a bit inflexible here. And the introduction of the "new" prefix looks like a hack, which doesn't even handle all situations. * The JVM instructions mentioned above can be categorized into two kinds: The first kind expects an object reference in addition to the actual arguments (invokeinterface, invokespecial, invokevirtual), the second kind doesn't (invokestatic). When we export a Haskell function to the JVM, how do we specify this distinction? static vs. dynamic? This means something slightly different in the case of ccall/wincall. What about typing? * How are C++/JVM exceptions handled? I fear that almost no real C++/Java code will be useable from the Haskell side if there is no way to catch these beasts or throw them. I hope I didn't sound too negative, that's not what was intended. It's only a mirror of the fact that there are a lot of loose ends in the spec and a multi-language FFI in a strongly type language is a rather ambitious (but very cool :-) project. Thanks to Manuel for his effort! Cheers, Sven