Hi, I want to use an Haskell function with the following type ::
string -> string from a C# programm.
I want to use hs-dotnet to bridge both worlds, the author claim that it's possible, but provide no sample of this case. The only samples provided are the one to use .net from haskell.
Does anyone got a sample of this use, or got an idea how to use it? (I used reflector on the bridging assembly but didn't understood a thing)
You can certainly call Haskell from C at least -- you use "foreign export" in the Haskell file, and GHC generates a C header which you can then import and use to call into Haskell from C.
I've not seen this done for the .NET bindings -- so I think it is best to ask both the author - Sigbjorn - and on haskell-cafe@ for examples.
Just as an update, I've solved the problem by making an haskell DLL and bridging the two worlds that way.
If you want to take the same path, be sure to use ::CoTaskMemAlloc to allocate data for the .net world. Another gotcha is the use of LoadLibrary/GetProcAdress, for some unknown reason, imports doesn't work automatically the way they're supposed to be. A more in depth article to help calling haskell from .net.
While your way works, it's worth noting that the dificulties you encountered were of your own doing unfortunately (and not a bug in GHC) :( (the following assumes you used the ghc documentation when building the dll and have your RTS loading in dll main).
for the first part, the memory allocation issues you present, there's a much easier C# native way of handling this. which is unsafe code. any memor allocated in unsafe code will be allocated outside the managed heap. So this would negate the need for C trickery.
The second part if the use of the loadLibrary in C#. The reason P/Invoke can't find your export is quite simple: in your haskell code you declared the export statement using ccall, while in .NET the standard naming convention is stdcall, which is also the standard for Win32 Api calls.
stdcall and ccall have different name manglings and resposibilities in term of argument cleanup.
in particular, GHC/GCC will have exported "wEval" while .NET by default would be looking for "_wEval@4". Now that's quite easy to fix, just add CallingConvention = CallingConvention.Cdecl.
but using this calling convention the caller needs to clean up the stack. So you would need extra work. Now assuming you're only going to use this on windows, just export your haskell function as stdcall. This makes your .net code simpler and makes
[DllImport("foo.dll", CharSet = CharSet.Unicode)]
public static extern string myExportedFunction(string in);
almost correct.
what's correct would be for example
[DllImport("foo.dll", CharSet = CharSet.Unicode)]
public unsafe static extern char* myExportedFunction([MarshalAs(UnmanagedType.LPWStr)]string in);
no more need for loadLibrary or the like. and to get a manage string just use
String result = new String(myExportedFunction("hello"));
for instance.
In theory
[DllImport("foo.dll", CharSet = CharSet.Unicode)]
[return : MarshalAs(UnmanagedType.LPWStr)]
public static extern string myExportedFunction([MarshalAs(UnmanagedType.LPWStr)]string in);
should work too, but I've had problems with this in the past.
if you want to stay completely in managed land, you could always do
[DllImport("foo.dll", CharSet = CharSet.Unicode)]
public static extern IntPtr myExportedFunction([MarshalAs(UnmanagedType.LPWStr)]string in);
and then it can be used as
string result = Marshal.PtrToStringAnsi(myExportedFunction("hello"));
Cheers, Phyx