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