It doesn't say anything about the ability of the owner to port F# to the JVM, but just know that it is just a readme, three almost empty java classes, and the beginning of an ANTLR parser.
So to answer other questions here, you can't even compare it to F# on Mono. F# on Mono works perfectly. The F# compiler and runtime is huge, and getting to parity will probably take at least a year to a very dedicated team.
That said, there is some very interesting work going on towards having a sane call out to JVM / .net code from haskell, though nothing will realistically be in a truly usable for in the next 12-18th months
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.
Most code containing P/Invoke calls into native Windows Libraries (as opposed to P/Invokes done to your own C libraries) will need to be adapted to the equivalent call in Linux, or the code will have to be refactored to use a different call. <-- Means when you choose to directly link to Windows technology.
Registry <-- If you choose to use it. I haven't written any registry dependent code for the last ten years and don't even miss anything about it.
you should not assume the order of bytes <-- Not .Net's problem.
... the list goes on.
(It's essentially what it says in the tin...)
By stagnation I mostly meant the comparatively tiny ecosystem of libraries vis-a-vis, e.g. JVM-based languages. In particular, with Akka, Scala has much nicer support for concurrency. The ability to call, and be called by, Java code in the smoothes possible way is also beneficial for my use cases.
I'm surprised that GADTs were added, because a few years ago I visited the Gallium team at INRIA who develop Ocaml, and asked about GADTs. I was told by one of the senior Ocaml developers that there were no plans for the inclusion on this feature.
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.
You must mean tail call optimization/elimination here. Clearly, the JVM supports tail calls.
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.
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.
The JVM most certainly does support general tail calls through its invoke instruction, which supports calls to arbitrary methods of arbitrary objects (which, of course, includes tail calls).
Some compilers also support the optimization of _some_ recursive tail calls (usually recursive tail calls to final or local methods) into loops using the goto instruction, which supports jumps within the current method (essentially optimizing the tail-recursive method into a non-recursive method containing a loop).
If I read you correctly, you say, the JVM 'supports tail calls', because it can call other methods. I think, the phrase 'supports tail calls' is as meaningful as 'supports function calls' then.
In any case, I don't think this is a question of optimization. I don't see how, for example, an F# program written in CPS can ever run on the JVM.
If it is important to you (it certainly is to me), use an implementation which supports proper tail calls.
I'm doing it and I have never looked back.
"A method annotation which verifies that the method will be compiled with tail call optimization. If it is present, the compiler will issue an error if the method cannot be optimized into a loop."
The issue is different for general tail call elimination.
This port is in very early stages, and only has the start of a lexer as far as I can see.
It's also available through the FreeBSD ports system:
More info on F# 3.0 + Mono 3.0 + FreeBSD can be found here:
Arch Linux users: the thread I linked also has instructions on how to build/install F# 3.0 and Mono 3.0, if you're interested.
Have a look at Yeti ?