Is it reasonable to require that only foreign declarations of a *single* foreign language are allowed per Haskell module?
We can have some declaration specifying the context of *following* foreign declarations. Another such declaration can change the context later in the module.
Please no! The foreign declaration context should be global, no matter where the declaration occurs in the file; it should not depend on an arbitrary ordering of text. To depend on ordering would make the sources difficult to comprehend, and introduce unnecessary complexity into the compiler.
Here is a concrete proposal:
foreign language "c",
I think the quotes around the language name are redundant - why not just foreign language C ?
foreign language "c", include "<ncurses/curses.h>", library "ncurses"
I quite like the idea of keyword/string pairs. I'm not sure how you would propose to use the layout rule here. To make them slightly easier to parse, why not make them like named-field bindings perhaps? foreign language C { include="<ncurses/curses.h>" , library="ncurses" } I suppose in the case where the C header was local, the string would need to use the Haskell double-quoting mechanism? include="\"local_header.h\""
I hope all interesting parameters in the future will fit in the syntax of keyword/string pairs, with the string being optional (some keywords are just boolean switches), or perhaps with multiple strings separated by spaces (multiple headers/libraries could be specified that way).
For booleans, use booleans flag=True and for multiple strings, use tuples? searchpaths=("dir1","dir2") Regards, Malcolm