I can appreciate Alastair's reluctance to make changes to the FFI
specification at this late stage. I would suggest that the rest of
us really want it to stay stable and solid too. But at the recent
implementers' meeting in Cambridge, it emerged that the current design
has one or two very small flaws. So, because Alastair wasn't at that
meeting where we discussed the possibility of some small changes,
I thought it might be useful to rehearse some of the motivation here
on the list.
First, Simon PJ and Erik Meijer have been thinking about whether the
current FFI story works adequately with Java as the foreign language
rather than C. (Ghc now has a backend that compiles to Java rather
than C or native code, so it makes sense to try to use foreign Java
code directly.)
The good news is that the FFI mostly goes through ok. The only points
where they need to extend the mechanism are:
foreign import [ccall|stdcall] "linklib" "foreignname" hname :: type
* Neither of the calling conventions 'ccall' or 'stdcall' are appropriate
for Java, so they suggested adding 'java' to the allowable set.
(This raises the prospect of continually having to add new calling
convention specifiers every time some compiler implementer gets a
brainstorm for a new backend target language.)
* The "foreignname" specification cannot be just the name of the
function/method in Java. For one thing in Java, the same name
can refer to lots of different methods distinguished by number and
types of arguments. For another, Java uses namespaces. So the
foreignname specifier ends up looking something like
foreign import java "int Foo.Bar.g(bool)" g :: Bool -> IO Int
But you will notice that this string encapsulates some of the
information that was originally supposed to be in the "linklib" part
of the specifier - namely "Foo.Bar".
* The obvious corollary is that in fact a single string would be
sufficient to specify both the "linklib" and "foreignname" specifiers
in C as well. Indeed, for an arbitrary foreign language, all you
need is to define the format of a single string, and the compiler
implements a mini-parser to extract the information it needs
(header / link-library / function name / namespace / whatever).
Ok, so at this point we discussed what is currently used in the
existing C foreign interface. It turns out that the current two-string
specifier of "linklib" and "foreignname" is not the whole story.
Sometimes (e.g. when compiling via C rather than native code) a
compiler needs a prototype for the foreign function. Nhc98 simply
generates a plausible prototype based on the Haskell type, but this
is wrong in general because the compiler cannot always correctly guess
the actual C prototype. For this reason, nhc98 has a non-standard hack
foreign import noproto "foreignname" f :: type
to fix those situations where it gets it wrong. Ghc on the other hand
never tries to generate a prototype, but this means it needs its own
non-standard hack, the compilation flag
-#include <header.h>
to get the correct prototype in almost all cases. Thus it seems
that when the FFI is targetted at C, it actually needs three strings,
not just two, for instance:
foreign import "<header.h>" "linklib" "foreignname" f :: type
So now we come back to the idea that a single string is actually
sufficient, provided we know how to parse it for the foreign language
in question.
We played a little bit with deciding how to format the string for C,
for instance:
foreign import "<header.h>/linklib/foreignname" f :: type
but the objection was raised that in a binding to a foreign library,
a large part of the string would be identical in all the specifiers.
Hence, finally, the proposal was that perhaps a single decl
foreign decl [c|stdcall|java|...] "<header.h> / linklib.dll"
could abstract all this information to a single place in the source
file. (Note, we didn't even talk at the meeting about the possible
syntax of such a decl - we have only started to discuss possibilities
now on this list.)
Does that help to motivate the current discussion a bit more Alastair?
Regards,
Malcolm
_______________________________________________
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
