FFI Report, CVS Id 1.5

[Manuel M. T. Chakravarty]

Fergus Henderson <fjh at cs.mu.oz.au> wrote,

> On 15-Jun-2001, Simon Peyton-Jones <simonpj at 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 at 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 at 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