Modification to foreign import/export

[Manuel M. T. Chakravarty]

Among other things, the FFI was one of the topics at the
recent Haskell Implementor's Meeting.  One specific issue
that was discussed following a proposal for better Java
support by SPJ and Erik Meijer was a change to foreign
import/export declarations.

For some languages (eg, Java) a simple function name is not
sufficient to identify an external function/method (eg,
because of overloading).  So, it seems like a good idea to
extend the string specifying the external function name to
contain more information.  This string should include all
information that is necessary to identify the external
entity uniquely.  This has two consequences:

(1) The interpretation of the string becomes dependent on
    the foreign language and

(2) the optional specifier of a dll in the current proposal
    should be folded into this string.

Re (1): We obviously need to identify the foreign language.  This
  can be achieved by extending the ccall/stdcall keyword to
  generally specify the foreign language (eg, we might use
  "java").

  After that change, I think, the keyword for C should be
  "c" rather than "ccall" (we are not writing "javacall"
  either).  Not sure what a good alternative for stdcall
  would be...win?  pascal?

Re (2): In Java, we obviously want to use qualified names
  (like "java.lang.foo"), but in the case of dynamic
  libraries and C calls it is less clear what the syntax
  should look like.  "gtk: gtk_new_window" to specify that
  the dynamic library "gtk" (on Unix that would happen by
  loading "libgtk.so") has to be loaded to call the function
  "gtk_new_window"?

The latter raises two further issues:

(a) When a compiler generating C code translates a module
    including C bindings, it should be given the name of the
    relevant header file, too. Generally, the name of the
    header and the dynamic library may be different.  So, we
    must be able to specify two names.

(b) Some of the language specific information (like the
    header file and the dynamic library) often is the same
    for all foreign declarations in a module.  It is
    annoying to have to repeat it in every declaration and
    makes it more difficult to alter conditionally.

Is it reasonable to require that only foreign declarations
of a *single* foreign language are allowed per Haskell
module?  Would one single global declaration of the relevant
information, then, be sufficient?  And do we want to specify
the foreign language used in this module in this global
declaration, too?

Summary of Open Points
~~~~~~~~~~~~~~~~~~~~~~

- Language specifiers: Other names for "ccall" (possibly, "c")
  and "stdcall".

- Header files: Syntax for specifying a header in case of a
  foreign declaration for C.

- Only one foreign language per Haskell module?

- Global specification of parameters such as the foreign
  language, dynamic library to be loaded, and header file to
  be included?

Opinions?

Cheers,
Manuel