[tigershark]

Yes, I agree, but you need to be really careful about tail call recursion optimisation when calling f# code from c#. In F# it is always guaranteed, in c# only on 64 bit 4 and above runtime if I remember correctly, so you can't really rely on it for production code.

[MichaelGG]

Unless it's changed, F# doesn't emit "tail." prefixes for tailcall. Nor is it guaranteed. The F# compiler will, in some cases, manually turn your tailcall-OK code into a loop. But it doesn't do it in all cases (nor could it).

The F# compiler used to emit "tail." prefixes in every case that was eligible. But not only does the CLR have lots of restrictions, it was slower to request tailcalls.

Maybe that changed in the last version or two.

Edit: OK I found the email where I had asked fsbugs why tailcalls were no longer generated. But that was in 2009 so I'm more out of date than I remember.

In the release notes[1] for the May 2009 release, there's this section:

Optimizations for Tailcalls

On some implementations of the CLI, normal calls can be more efficient than tailcalls. An optimization is now applied to determine if a function is “closed” in the sense that it never takes any tailcalls outside a finite non-recursive callgraph. If so, the use of tailcalls is suppressed.

1: http://blogs.msdn.com/dsyme/archive/2009/05/20/detailed-rele...

[RaleyField]

Wouldn't C# interface only with compiled il code and not directly with F# so any tail call optimizations in F# wouldn't depend on what you later do in C# compiler?

[tigershark]

Yeah, right, the f# compiled code will be already optimised for the tail call recursion so it can be called safely from the c# code. What I remembered applies only to the c# generated IL.