3 ms·

The ecosystem is great, but it has its own limitations. For example, to my knowledge Scala has not been able to implement tail recursion optimization, citing JV

The ecosystem is great, but it has its own limitations. For example, to my knowledge Scala has not been able to implement tail recursion optimization, citing JVM limitations.

vvillena 10y ago
Tail recursion is fully supported in Scala. The problem lies in more general recursion, i.e. two functions that call each other recursively will grow and eventually blow the stack. BTW, there is a Scala compiler annotation that helps you check whether a function is tail-recursion optimized.
- dtech 10y ago
  You're talking about two different "tail call optimizations" here. Scala supports local tail call optimization for a single function. A lot of FP languages support mutually recursive tail call optimizations, where two functions recursively call each other (common in FP). Scala (and no JVM language to my knowledge) cannot optimize this and so programmers have to resort to workarounds like Trampolines. In contrast, LLVM IR and .NET CLR support it, allowing language compilers to use it. F# supports it and there's plans for C# to support it. It might be supported in the LLVM Scala target (Scala native) at some point in the future.
pron 10y ago
Sure, and one day the JVM will get TCO just as it's getting value types (which is perhaps an even bigger current shortcoming), but that is a small price to pay for the ecosystem.
- lomnakkus 10y ago
  > Sure, and one day the JVM will get TCO just as it's getting value types You're more optimistic than I am. And honestly proper TCO doesn't seem to be all that important to "regular" java programmers[1], it's just that it's crucial for $ALT_LANGUAGE implementers. (Where ALT_LANGUAGE has a functional flavor.) [1] I'm guessing that this is the reason that it hasn't been prioritized... but who knows what complexity would rear its ugly head if one were to actually try to implement TCO on the JVM... I'd hazard a guess that it's 'highly non-trivial'.
  - mike_hearn 10y ago
    The JVM is full of large projects that are only relevant to non-Java languages, like the vast bulk of java.lang.invoke, the Graal/Truffle projects etc. They've seemed serious about non-Java languages for a long time now. However/unfortunately, almost all the work has gone into support for dynamically typed languages like Ruby or JavaScript. Given the relative popularities of dynamic vs FP languages that's not surprising. If FP languages that relied on TCO were far more popular it'd probably have been prioritised already.

The ecosystem is great, but it has its own limitations. For example, to my knowledge Scala has not been able to implement tail recursion optimization, citing JVM limitations.

vvillena 10y ago

Tail recursion is fully supported in Scala. The problem lies in more general recursion, i.e. two functions that call each other recursively will grow and eventually blow the stack. BTW, there is a Scala compiler annotation that helps you check whether a function is tail-recursion optimized.

dtech 10y ago
You're talking about two different "tail call optimizations" here. Scala supports local tail call optimization for a single function. A lot of FP languages support mutually recursive tail call optimizations, where two functions recursively call each other (common in FP). Scala (and no JVM language to my knowledge) cannot optimize this and so programmers have to resort to workarounds like Trampolines. In contrast, LLVM IR and .NET CLR support it, allowing language compilers to use it. F# supports it and there's plans for C# to support it. It might be supported in the LLVM Scala target (Scala native) at some point in the future.

pron 10y ago

Sure, and one day the JVM will get TCO just as it's getting value types (which is perhaps an even bigger current shortcoming), but that is a small price to pay for the ecosystem.

lomnakkus 10y ago
> Sure, and one day the JVM will get TCO just as it's getting value types You're more optimistic than I am. And honestly proper TCO doesn't seem to be all that important to "regular" java programmers[1], it's just that it's crucial for $ALT_LANGUAGE implementers. (Where ALT_LANGUAGE has a functional flavor.) [1] I'm guessing that this is the reason that it hasn't been prioritized... but who knows what complexity would rear its ugly head if one were to actually try to implement TCO on the JVM... I'd hazard a guess that it's 'highly non-trivial'.
- mike_hearn 10y ago
  The JVM is full of large projects that are only relevant to non-Java languages, like the vast bulk of java.lang.invoke, the Graal/Truffle projects etc. They've seemed serious about non-Java languages for a long time now. However/unfortunately, almost all the work has gone into support for dynamically typed languages like Ruby or JavaScript. Given the relative popularities of dynamic vs FP languages that's not surprising. If FP languages that relied on TCO were far more popular it'd probably have been prioritised already.