RE: FFI Report, CVS Id 1.5
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
On 15-Jun-2001, Simon Peyton-Jones <simonpj@microsoft.com> wrote:
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
The main problem with that is that in general there will not be any relationship between the DLL name and the header name. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit | of excellence is a lethal habit" WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
Fergus Henderson <fjh@cs.mu.oz.au> wrote,
On 15-Jun-2001, Simon Peyton-Jones <simonpj@microsoft.com> wrote:
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
The main problem with that is that in general there will not be any relationship between the DLL name and the header name.
In particular, this encourages non-portable code. Assume, I develop a Haskell-to-C binding for a library whose header file is called `myheader.h' and whose dll is `mylib.dll'. Now, when I develop this binding in a fully statically compiled environment, I might use foreign import ccall "myheader::foo" foo :: Int -> Int and make sure that the right library `mylib.dll' is linked against in the command line options to the compiler. Now, if I run the same code on .NET, it breaks as it attempts to load `foo' from `myheader.dll'. "Simon Peyton-Jones" <simonpj@microsoft.com> wrote,
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
IMHO, this is not a very attractive solution. I'd prefer to complicate the ccall entity description slightly and go for foreign import ccall "myheader.h foo@mylib" foo :: Int -> Int Ie, we optionally allow the specification of the name of a dll. This is only a hint and may be ignored by a given Haskell system (in particular, in most systems, command line options overrule such library names). Any objections? Cheers, Manuel
participants (3)
-
Fergus Henderson -
Manuel M. T. Chakravarty -
Simon Peyton-Jones