On Sat, 30 Jul 2011, KC wrote:

Are there plans a foot (or under fingers) to make a version of Haskell that runs on the JVM?

http://www.haskell.org/haskellwiki/GHC:FAQ#Why_isn.27t_GHC_available_for_.NE...

On Sat, 2011-07-30 at 15:07 -0700, KC wrote:

A language that runs on the JVM or .NET has the advantage of Oracle & Microsoft making those layers more parallelizable.

On top of the answers you've got regarding whether this exists, let me warn you against making assumptions like the above. There are certainly good reasons for wanting Haskell to run on the JVM or CLR, but parallelism doesn't look like one of them. The problem is that the cost models of things on the JVM or CLR are so different that if you directly expose the threading and concurrency stuff from the JVM or CLR, you're going to kill all the Haskell bits of parallelism. A huge contribution of Haskell is to have very light-weight threads, which can be spawned cheaply and can number in the tens of thousands, if not hundreds of thousands. If you decide that forkIO will just spawn a new Java or CLR thread, performance of some applications will change by orders of magnitude, or they will just plain crash and refuse to run. Differences of that scope are game-changing. So you risk, not augmenting Haskell concurrency support by that of the JVM or CLR, but rather replacing it. And that certainly would be a losing proposition. Maybe there's a creative way to combine advantages from both, but it will require something besides the obvious one-to-one mapping of execution contexts. -- Chris

KC> Are there plans a foot (or under fingers) to make a version of KC> Haskell that runs on the JVM? This is probably a fun - or even useful - project, and a lot of people have had this wish of a general convergence of language runtimes toward a single VM such as the java one or the .net one. But I really hope this will never become an official GHC target, with any kind of commitment to support it. The Haskell/GHC tandem is based on concepts that are decades ahead of what is supported in mainstreams VMs, or even what will be supported in the next decade (see the changelog of the lastest Java release for fun). I don't know if it still current, but the Scala crew made considerable effort to support limited tail call optimization, because the JVM couldn't provide support for it. That shows how hard basic functionnal concepts don't map well on the JVM. I think nobody wants Haskell/GHC momentum to be slowed down by supporting limited backends. Neither we want Haskell-on-JVM benchmarks to show up everywhere on the web as "haskell benchmarks" (figures would probably be bad, because some basic optimizations or cost-model choices can't be applied to the JVM). Neither we want the web to be filled with Haskell-On-Java(|.Net) code snippets starting with Java-(|.Net)-specific imports at the top of the file. Haskell and GHC are amazing projects that make me like my job and have great hopes for the future of computer engineering ! :) -- Paul

On Sun, 31 Jul 2011 00:07:23 +0200, KC wrote:

Are there plans a foot (or under fingers) to make a version of Haskell that runs on the JVM?

UCH has an almost fully functional backend for JVM, see: http://www.cs.uu.nl/wiki/bin/view/Ehc/UhcUserDocumentation#5_7_2_jazy_Core_b... Regards, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html --