Modification to foreign import/export
Manuel M. T. Chakravarty
chak at cse.unsw.edu.au
Fri Feb 2 08:14:56 EST 2001
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
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
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
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
Summary of Open Points
- Language specifiers: Other names for "ccall" (possibly, "c")
- 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
More information about the FFI