FFI Report, CVS Id 1.5
simonpj at microsoft.com
Fri Jun 15 05:52:09 EDT 2001
I'm trying to compile Haskell for the .NET platform.
For this platform it makes perfect sense to say
foreign import ccall "foo" foo :: Int -> Int
because you can make C calls on .NET as well as .NET calls.
The problem is that the call must specify which DLL the
function comes from. The line in the .NET assembly code
looks something like
I remember now that this is why I originally suggested that
the C calling convention specify a "package name" rather
than a header file name. Thus
foreign import ccall "wuggle::foo" foo :: Int -> Int
rather than wuggle.h
Now I didn't follow all the details of why this was a bad idea
but I thought I'd mention the problem. My preference would
be to specify "wuggle" as the package name in the C entity,
and attach a ".h" to it when emitting code for certain common
platforms. The programmer would need to provide a suitable
.h file, if necessary simply by #including the ones really needed.
I'm conscious that this is resurrecting old territory; if it's been
done to death already, just say 'no'.
I suppose in that case I will have to add an extra .NET form
foreign import dotnet "callC wuggle::foo" foo :: Int-> Int
More information about the FFI