What does all this complexity buy us?
The ability to specify #include files in a portable way,
Can this not be done with one small extension instead of a much larger general purpose extension?
If a Haskell implementation needs to know from which library to take which function, e.g. an interpreter using dlopen/dlsym, then again this must be specified somehow. We could invent a way to encode it in the foreign function name, but [...]
The ffi spec already has a way to specify this: list it with each ffi decl. There's no need to invent anything new. I'm looking for a compelling argument that the convenience of adding all these extra declarations outweighs the costs of a more complex design, introducing more keywords into the language, etc.
When I import many stdcall functions, I must currently write stdcall with each declaration.
Can't you just add the required functionality (global library declarations, global calling convention declarations, order-dependent overriding, etc.) to hsc2hs?
Why I should be require to wrap everything in C if the compiler can be designed to do that for me?
Why not write a preprocessor that turns ffi/Java into ffi/C? Chances are that one of the existing calling conventions (i.e., stack and register layouts) and the existing set of types is going to be a pretty good fit. If you find yourself using a Haskell implementation that runs on a JVM and want to optimize it (e.g., support some Java types more directly), you can tweak ffi/Java to generate native Java or marshall some types more intelligently or whatever. A compiler flag can turn this on or off.
Surely maintaining just a C compiler is easier than maintaining both C and Haskell compilers. So what, abandon Haskell because using C for everything is simpler for compiler writers?
I'd describe what I want as follows: Keep the ffi standard simple so that: 1) An already hairy piece of code doesn't become unmaintainable. 2) Incompatabilities between different implementations can be kept to a minimum. And the way to achieve this is to put any proposed complexity in tools rather than in the ffi.
ps Could I propose that any proposed new keywords be prefixed by __ or ffi_ or something like that. [...]
Of course they are not keywords in any context except foreign language declaration. That's why I wrote "pseudokeywords".
I hope you don't mean anything like Haskell 98's "as", "qualified" and "hiding" special identifiers? Those have to be one of the worst features in the entire Haskell syntax. Surely there's a better way? -- Alastair Reid