Fjord – F# programming language for the JVM (opens in new tab)

surely you could just run lljvm on the llvm IR that ghc emits and have haskell code on your JVM?

I am not so sure if Frege would be of interest for people that look for an impure, strict language. A better fit for that would be Yeti.

And assuming that porting a language that is so deeply rooted in the .NET world like F# is very difficult, my guess is that going with Yeti and thus fully embracing the JVM will be a better choice. The more so as one could do this right now.

What's the quality of code produced by Mono? How does it compare with Microsoft's compiler? I'd like to see Mono C# and F# numbers compared against Microsoft's compilers. Will I get 90% of the performance?

Some examples of why .NET is a Windows technology:

http://www.mono-project.com/Guidelines:Application_Portabili...

it's tied in the sense than the madurity over mono is a really long distance over the net one...I try use mono and f# in win xp..the answer was.."you can't...install w7 and vs2012"...that is annoying...the "mono community" are only a few guys compared to the .net support...so yes...it is really tied to .NET.....

It's really not. Scala is a very interesting language, and it incorporates many functional features, but it's not at all ML-like. In particular, type annotations are needed in many, many places where they would be superfluous in an ML-derived language.

That may not be a practically relevant difference. Why would you want to run F# on the JVM? To interface with JVM code. IKVM lets you do that already.

I've rolled out multiple .NET programs that contain Java open source libraries through IKVM. It works just fine, and the amount of extra work you need to do to make the JVM->.NET mapping work is remarkably little.

Plus, as it is relatively simple to perform tail call elimination with iteration instead of reusing the frame in many (most?) cases, static analysis can classify those cases and hygienically rewrite those functions.

Most attempts I've seen to exploit TCO either aren't optimizations or can be dealt with via another control mechanism. My suspicion is that it is largely a solution in search of a problem for the programmer attempting to employ the technique, much like using AOP to add logging information for every "enter" and "return" from a method/function.

Mind you, I am in no way dismissing tail-call elimination as an important tool. Just that some of its practitioners (such as whichever idiot who wrote some of the barely-readable code in old programs of mine!) are a bit zealous in its use.

If you want to be pedantic, the JVM does not support tail (function) _calls_, but jumps, which may be the result of tail call optimization or elimination.

As far as I know, we still cannot efficiently turn mutual recursive calls into a chain of jumps, but I'll be glad to be corrected here.

I think everyone knows what he meant. In programming, everything supports everything anyhow, as long as it's Touring complete.

scala doesn't optimize general tail calls, either (only direct tail recursion of final methods). If you want to optimize tail calls on the JVM, you must use trampolining, which adds some overhead to every call. So most languages choose fast calls without tail call elimination over slower calls with tail call elimination (i.e., speed over correctness).

Someone has made TCO possible in Clojure already: https://github.com/cjfrisz/clojure-tco

Clojure has a loop/recur construct which makes the tail recursion explicit so doesn't need to be done by the JVM. In other words regular recursive calls should not be used for loops if you want performance.

I'd say that's a huge performance hit (return, check, call instead of jump). Plus, your JIT might not like it.

F# works very well in Osx and with Xamarin Studio you can target a lot of different platforms: Windows, Osx, Android, and iOS.

FYI, F# 3.0 is shipped as part of the Mono package for OS X.

It's also available through the FreeBSD ports system: http://www.freshports.org/lang/fsharp/