IIRC, as you said, for most tail-end recursion, you'll find that the IL that F# generates is actually a simple loop with a mutable variable. In cases where there's continuations involved or more complex scenarios with multiple recursive functions, F# will automatically provide the CLR with the .tail instruction. Work has gone into the CLR to better support tail end recursion, and there have been lots of fixes in recent versions (e.g. going back a couple of years, there used to be scenarios where the JIT would ignore the flag, but have been fixed).
I've never run into an issue myself, although infrequently I have heard of corner-cases that still pose issues (e.g. http://blogs.msdn.com/b/dotnet/archive/2015/07/28/ryujit-bug-advisory-in-the-net-framework-4-6.aspx ). However, I've also heard it said that when it comes to tail-end recursion F# is in a better place with the CLR than Scala is with the JVM. And both are used in production even in financial institutions. Given that I (rarely) still run into other bugs in the .Net framework with C#, I don't see this as anything different; testing (including on different platforms) is a necessary part of application development, and with F# it's no different. On 8 September 2015 at 13:58, Thomas Koster <[email protected]> wrote: > Hi friends, > > When I first heard of F# a few years ago I laughed out loud, but its > popularity is exploding, and .NET pays the bills, so I am forced to take > it a little bit more seriously these days. > > Tail call elimination in .NET is a *hint only* that JIT is free to > ignore in many situations [1], including: > - in debug builds, > - when calling virtual methods, > - when calling a method in a different security trust group, > - in any other case where an "implementation-specific restriction > prevents the 'tail.' prefix from being obeyed." > > Yet tail call elimination is *essential* to the correct functioning of > programs written in any functional programming language. > > F# appears to eliminate tail calls to self by program transformation > where it is trivial to do so, but relies entirely on the CLR for > optimizing tail calls in general. This would mean that the stability and > reliability of programs written for the CLR in F# is uncertain, and that > debug builds of F# programs are always unreliable. I would want much > stronger guarantees about space complexity if I were to seriously > consider F# as a programming language for paid work. > > So if anybody has used F# in the real world, what's the story? > > [1] "Common Language Infrastructure (CLI)" 6e, ECMA-335, III.2.4 > > -- > Thomas Koster >
