A process comment: This FFI discussion is dragging. I really want to get a conclusion because I want to implement it for .NET. Manuel --- you are are Tzar. Whip us into order! (I don't think that any of the issues are do-or-die ones; i.e. compromise is possible!) | > > [...] What's the advantage of putting the information in a string? | > [...] This is useful for tools that parse Haskell source code but | > which are not compilers -- e.g. documentation generators. | | That's not really an argument, because if we slightly change | the grammar, a "catch-all" production is easily specified: But only if the catch-all production catches all. For example, suppose we wanted to specify the full type signature of a Java function. In principle we could specify a grammar that would describe foreign import jvm static int Java.Lang.foo( int x ) foo :: Int -> IO Int But it's hard to parse without the newline, and it's going to be hard to specify a catch-all syntax that enables the documentation generator to skip all the jvm-specific junk. I think we should stuff it into a execution-platform-specific string, thus foreign import jvm "static int Java.Lang.foo( int x )" foo :: Int -> IO Int What should be visible "outside" the string. I think: a) what Haskell function is being defined or used b) what the Haskell type of that function is c) whether the function is being *defined* (like foreign import or foreign export dynamic) or *used* (like foreign export) Haskell functions that are *used* must be in scope already; those that are being *defined* are brought into scope by the foreign decl. Unfortunately, 'foreign export dynamic' defines a function, so one cannot just look at the import/export keyword. Maybe we need foreign import foreign export foreign dynexport ? (Dynamic import is quite different; it's still an import, but there's one more argument.) Simon