Modification to foreign import/export

[malcolm-ffi at cs.york.ac.uk]

> > 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