Modification to foreign import/export

malcolm-ffi at malcolm-ffi at
Mon Feb 12 12:27:36 EST 2001

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


> 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


and for multiple strings, use tuples?



More information about the FFI mailing list