FFI Report, CVS Id 1.5

[Simon Peyton-Jones]

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

	pinvoke dllname::foo 

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

Simon