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