Great! Are there any chances of getting support for non-Win32 platforms with Mono? On Fri, Oct 10, 2008 at 2:12 PM, Andrew Appleyard wrote:

I'd like to announce the first release of Salsa, an experimental Haskell library that allows Haskell programs to access .NET libraries.

Here's a taste:

...

type Hello.hs import Foreign.Salsa import Bindings

main = withCLR $ do _Console # _writeLine ("Hello .NET World!")

...

type Hello.imports System.Console: WriteLine

...

msbuild .\hello Hello .NET World!

Salsa operates by loading the .NET runtime into your Haskell process and using the FFI (and run-time code generation) to marshall calls between the .NET and Haskell runtimes. It includes a code generator and a type-level library (which uses type families) to provide type-safe access to .NET libraries in Haskell with C#-style method overload resolution and implicit conversions.

The adventurous can find version 0.1.0.1 of Salsa on Hackage [1], the darcs repository on code.haskell.org [2], and some (limited) documentation on the Haskell wiki [3].

The library is experimental and by no means complete (refer to the wiki page [3] for some of its limitations). Be prepared to end up with incomprehensible error messages and/or a broken compiler! :-)

At the moment you'll need Windows, GHC 6.8, and version 3.5 of the .NET Framework to use it.

Have fun!

[1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Salsa [2] http://code.haskell.org/Salsa [3] http://haskell.org/haskellwiki/Salsa

-- Andrew _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

This could be a game changer. Great work Andrew!! -- Don andrew.appleyard:

I'd like to announce the first release of Salsa, an experimental Haskell library that allows Haskell programs to access .NET libraries.

Here's a taste:

...

type Hello.hs import Foreign.Salsa import Bindings

main = withCLR $ do _Console # _writeLine ("Hello .NET World!")

...

type Hello.imports System.Console: WriteLine

...

msbuild .\hello Hello .NET World!

Salsa operates by loading the .NET runtime into your Haskell process and using the FFI (and run-time code generation) to marshall calls between the .NET and Haskell runtimes. It includes a code generator and a type-level library (which uses type families) to provide type-safe access to .NET libraries in Haskell with C#-style method overload resolution and implicit conversions.

The adventurous can find version 0.1.0.1 of Salsa on Hackage [1], the darcs repository on code.haskell.org [2], and some (limited) documentation on the Haskell wiki [3].

The library is experimental and by no means complete (refer to the wiki page [3] for some of its limitations). Be prepared to end up with incomprehensible error messages and/or a broken compiler! :-)

At the moment you'll need Windows, GHC 6.8, and version 3.5 of the .NET Framework to use it.

Have fun!

[1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Salsa [2] http://code.haskell.org/Salsa [3] http://haskell.org/haskellwiki/Salsa

-- Andrew _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Fri, Oct 10, 2008 at 5:12 AM, Andrew Appleyard < andrew.appleyard@gmail.com> wrote:

I'd like to announce the first release of Salsa, an experimental Haskell library that allows Haskell programs to access .NET libraries.

Wow, that's really great. I have a .NET friendly employer, so I'm happy to see a tool/library that 'bridges" the gap between my dream of using Haskell on the job and my reality of using .NET on the job. Thank you for releasing this! Salsa operates by loading the .NET runtime into your Haskell process and

using the FFI (and run-time code generation) to marshall calls between the .NET and Haskell runtimes. It includes a code generator and a type-level library (which uses type families) to provide type-safe access to .NET libraries in Haskell with C#-style method overload resolution and implicit conversions.

That's a very pragmatic approach. Nice. But, as I understand it the Haskell you write still lives in Haskell-land and the .NET code you interface with lives in .NET land. So this means, that if we tried this approach with other languagse, say Python and Java, our Haskell code would be a second class citizen there. For example, suppose you embed CPython into an application and then build a Haskell <--> Python bridge. Then my Haskell code I write must be recompiled for each platform and loaded by the python? Similarly for Java, I'm assuming that while the JVM bytecode might get loaded by the security module my Haskell is living in Haskell-land and the JVM can't provide the users with the same guarantees. So, what about translators? I was thinking, maybe a nice way to interoperate would to translate Haskell to language du jour? What if I could type, ghc --make Foo.hs -TPython, and I get Foo.py that can be run in the CPython implementation as just plain python? My understanding is that changing GHC backend is a lot of work. Take projects like lambdaVM, which I don't think has ever been completed, and you see that it involves writing a language specific run-time and some other work. There is yhccore, which has a translator for javascript. What is the way to go here? I like GHC in terms of performance, robustness and language extensions. Would I lose that with custom backends? I imagine the language extensions I'd get to keep and everything else would be subject to how well the backend is written. What do others think? Thanks! Jason

Great! Thanks for putting the code out! Manuel