43

I'm a .NET developer by day, but have been playing with Haskell in my spare time for awhile now. I'm curious: any Haskell .net implementations in the same vein as IronPython?

Arialdo Martini
  • 4,427
  • 3
  • 31
  • 42
Will
  • 433
  • 1
  • 4
  • 6
  • Have you seen the [H# website](http://www.cin.ufpe.br/~haskell/haskelldotnet/)? (Actually, that site looks quite... dead to me.) – stakx - no longer contributing Jul 16 '10 at 21:44
  • @stakx: "Latest News: 2003-12-13" Yeah, I saw that. :) – Will Jul 16 '10 at 21:57
  • **Even if you find a satisfying platform**, it's important that you check out [Rei's answer here](http://stackoverflow.com/a/3269215/825637) because it can't be disregarded that the CLR isn't built for this. – MasterMastic Apr 19 '14 at 20:26
  • I always thought it was because someone was scared of calling it H# because it might annoy music majors. But in my eyes, that's really just a good reason to make it happen. – Hakanai Nov 16 '22 at 07:30

4 Answers4

34

There's no active work on porting the GHC runtime to .NET.

F# is the closest thing, though be aware it is based on OCaml.

One of the core differences is, that Haskell is always lazy, while OCaml and F# evaluate mostly strict, and lazy just in some special cases.

There are many similarities besides that. All three do focus on referential transparency by default, and have very good type inference, as an example.

Matthias Schuster
  • 113
  • 1
  • 6
Don Stewart
  • 137,316
  • 36
  • 365
  • 468
  • 2
    can you expand on why referential transparency by default is a good thing? – knocte Feb 17 '14 at 12:07
  • 4
    @knocte Because that way you can't just throw in side-effecting operations and immutable state is enforced much more strongly, leading to code that can be reasoned about more easily (and less bugs). – Joshua Grosso Reinstate CMs Dec 10 '15 at 17:02
16

See hs-dotnet: Pragmatic .NET interop for Haskell

hs-dotnet is a pragmatic .NET interop layer for Haskell. It exposes both .NET classes to Haskell (via GHC) and Haskell function values to .NET.

Contango
  • 76,540
  • 58
  • 260
  • 305
11

Haskell wouldn't readily work very well on .NET without some big changes to the runtime or maybe a really clever compiler.

Maybe things will change when code contracts permeate more, but right now, even functions that actually are pure in behavior, like the string manipulation functions, would have to be accessed via IO -- so it just wouldn't be worth it at all.

That, and there are optimization issues -- .NET doesn't do any optimizations for immutable objects, for instance, so lists (sequences as they're called in F#, or IEnumerable as they're called in C#) wouldn't be as efficient.

A Haskell IL compiler might be doable, like something that spits out .NET assemblies instead of x86 .exes/.dlls.

Rei Miyasaka
  • 7,007
  • 6
  • 42
  • 69
  • While this question is specifically about .NET, I'm curious whether the same arguments hold if Haskell were to run on the JVM. Does the JVM, for example, do any more optimizations on immutable objects than the CLR? – stakx - no longer contributing Jul 16 '10 at 23:59
  • 3
    As far as I know, the situation is the same with immutability. I imagine optimizing immutability is pretty darn complicated, balancing memory and performance costs and such. The garbage collector would probably look different too, and JVM and .NET share similar garbage collectors. One thing that .NET 4 has is tail recursion optimization, which helps to simplify functional compilers -- but they only provided it for x64 and not for x86, which is a decision that baffles me beyond words. – Rei Miyasaka Jul 17 '10 at 00:25
  • 1
    @stakx: If you really want to know, I'm sure there's plenty of material on that subject from the people working on Scala and Clojure. If memory serves me, Clojure in particular places heavy emphasis on immutable data. – C. A. McCann Jul 17 '10 at 00:26
  • 1
    @JonHarrop Only in F#, not in JIT. – Rei Miyasaka Apr 22 '14 at 07:31
  • @ReiMiyasaka: I believe that is incorrect. The .NET JIT does TCO on x86, nothing to do with F#. It is required for tail calls to work correctly in the general case in F#. For example, see "The 32-bit JIT had a general purpose tail call mechanism that always worked" http://blogs.msdn.com/b/clrcodegeneration/archive/2009/05/11/tail-call-improvements-in-net-framework-4.aspx – J D Apr 23 '14 at 18:38
  • @JonHarrop Ah, I missed the subtlety that follows that: "...but wasn’t performant enough to consider it an optimization, so it was only used when the IL requested a tail call." – Rei Miyasaka Apr 24 '14 at 11:03
4

There is no .net Haskell that I know of, but another functional language is available: F#. It runs in .NET and comes with Visual Studio. They are similar to a point; this stackoverflow question explains the differences.

Here's the documentation on getting started with F#.

Arialdo Martini
  • 4,427
  • 3
  • 31
  • 42
redtuna
  • 4,586
  • 21
  • 35