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 implemenations in the same vein as IronPython?
derp (more text)
Brad Heller
2010-07-16 21:46:25
I don't know either Haskell or F# well enough to compare, but in terms of functional languages on the .NET platform, I suspect that F# will corner the market simply because it's supported by Microsoft and included in Visual Studio (starting with 2010, but you can get plugins for previous versions of VS).
Thomas Owens
2010-07-16 21:46:45
No, F# derives from OCaml which is a different story than Haskell which draws more from LISP.
Johannes Rudolph
2010-07-16 21:47:59
@Johannes Rudolph: What? No, Haskell has very little in common with LISP, but is a (somewhat distant) cousin of the ML family. F# also draws a few bits of additional inspiration from Haskell, as does C# for that matter, and much of the work done on Haskell as a language is funded by Microsoft Research.
camccann
2010-07-16 21:51:55
@camccan: I didn't want to overstate that LISP thing but it certainly has more in common with LISP than with OCaml. Correct me if me or http://en.wikipedia.org/wiki/Haskell_(programming_language) is wrong here.
Johannes Rudolph
2010-07-16 22:07:25
@Johannes Rudolph: As far as I can see, the Wikipedia page only mentions LISP in the rather vague "influenced by" sidebar section, which still names more MLs than Lisps. Lisp and Haskell are nearly as unlike each other as two functional languages can be, and I could probably formulate a plausible argument that modern **C#** has more in common with Haskell than does Common Lisp, nevermind F#.
camccann
2010-07-17 00:21:19
@Johannes: Through its static typing, type inference, and algebraic data types, Haskell is *much* more closely allied with Standard ML, Objective Caml, and F# than it is with any language in the Lisp family. And if you read something about programming languages on wikipedia, it is probably wrong---I don't know who writes this stuff, but I have given up trying to fix it. I'm not willing to shovel against the tide. The quality of information is much better on SO.
Norman Ramsey
2010-07-17 00:22:24
@Norman: Thanks for enlightening me.
Johannes Rudolph
2010-07-17 08:36:16
+2
A:
There is no .net Haskell that I know of, but another functional language is avilable: 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#.
redtuna
2010-07-16 21:45:32
+10
A:
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, and as such, isn't based on referential transparency by-default, as Haskell is.
Don Stewart
2010-07-16 21:45:49
+5
A:
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
2010-07-16 22:14:47
@Rei Miyasaka: 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
2010-07-16 23:59:38
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
2010-07-17 00:25:36
@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.
camccann
2010-07-17 00:26:57