[Haskell-cafe] ANNOUNCE: Salsa: A .NET Bridge for Haskell

[Jason Dagit]

On Fri, Oct 10, 2008 at 5:12 AM, Andrew Appleyard <
andrew.appleyard at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081010/0cf21f99/attachment.htm