The first time I read this syntax, I misinterpreted it. I think my misinterpretation might be interesting so I'll give it below in case anyone else likes it.
foreign library C "<ncurses/curses.h>" "-lcurses" foreign library java "blah" "blah"
foreign import C "curses_function" cf :: Int -> IO Int foreign import java "java.blah.*/foo" jf :: Int -> IO Int
What I first thought this was doing was: 1) The foreign library decls _declare_ two new kinds of external function which the programmer as arbitrarily (and confusingly) chosen to call "C" and "java". 2) The foreign import declarations refer to these new kinds of external function. Those declared as "C" will use <ncurses/curses.h>, etc. Those declared as "java" will use "blah", etc. Of course, this interpretation doesn't quite work because if "C" is just an arbitrary varid with no particular meaning, then we need to say somewhere else that "C" is to use the C calling convention. (We also need to change "C" to "c" if it is going to be a varid.)
A module can have one "foreign defaults" declaration per calling convention, which specifies a string.
foreign defaults ccall "<gtk/gtk.h>: " foreign defaults java "java."
Alastair ps Just as a general remark on language design... User defined defaults are really tempting to add (my component programming language had them briefly and I am under constant pressure to add them back in) but they are kinda messy because: 1) You have to resolve (or forbid) use of multiple defaults. 2) You need a way to override the default. Do you override the whole default (includes, libraries, etc.) at once or only the bits you don't specify. The latter seems to be slightly better than the former because defaults are sorta invisible - the programmer forgets that they're there and so they forget that overriding the default will zap all the default not just the part (libraries say) that they're thinking about at that moment. 3) A small change to code in one place can have unexpected results (and it is hard to detect the consequences using typechecking or from a failed link or whatever). 4) Cutting and pasting some code from one context to another context results in very different behaviour because the defaults don't carry over. [I think every form of default behaviour in the Haskell spec has caused problems like this way out of proportion to the apparent difficulty of specifying the meaning of defaults and the difficulty of implementing it.]