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.

Maybe someone who knows Scala or Clojure internals can answer this question..

Can't you lambda-lift & fully CPS-convert the code somewhere throughout compilation, then use a trampoline at runtime?

Or perhaps you'd wish to run F# on the JVM because you like the language, but don't wish to depend on .NET (or Mono).

No. Those are examples of portability issues when your application depends on platform specific functionality:

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.

(Replying to myself, since I can't edit the post now...)

More info on F# 3.0 + Mono 3.0 + FreeBSD can be found here: https://groups.google.com/forum/?fromgroups=#!topic/fsharp-o...

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.

Scala has a similar explicit @Tailrec annotation for its compiler, too:

"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."

http://www.scala-lang.org/api/current/index.html#scala.annot...

I think rail recursion can be handled automatically by the compiler without any support from the jvm (scala does it).

The issue is different for general tail call elimination.

That's very cool. But note that as far as I can tell it only handles mutual recursion, not arbitrary tail calls (e.g. calls to a function argument).

could you get the kind of adhoc library interop you get with other on-the-jvm languages like this with llvm?

This isn't really fair: some implementations really do rule out certain optimizations. Turing-Completeness only refers to what is computable, not what actual algorithms and optimization techniques are possible.

I think there may be a misconception here: A tail call is NOT a call that doesn't allocate a stack frame. A tail call is a call that is the return value of a function. This is why we refer it the stack frame-eliminating optimization as "tail call elimination". We are taking a jump-to-subroutine (call) instruction and replacing it with a normal jump instruction, thus eliminating a "call" from our program.

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).

Scheme implementations will compile any tail calls into jumps, even if they're mutually recursive. This is easy to understand by doing CPS transformation by hand on such calls.

As a recent migrant from Ocaml to Scala (due to stagnation of Ocaml), I have to say that you are quite right about type-annotations, but the style of programming that an Ocaml/F# person would be accustomed to is quite easily replicable using Scala.

There are games running on Mono (e.g. Unity C# scripts, Bastion was ported to Mono to run in Chrome, etc..). I'm sure the performance of Mono may depend on your specific application but many people have been using it without any issues.

Depends on what you're doing. Mono 3.0 has a stable llvm backend. For low level code it should run as fast as c modulo array bounds checks etc.

Support for tail calls pretty much depends on the actual runtime implementation.

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.

This is very cool. Thank you!