Question

As a Scala newbie, I’m reading books, docs and try to solve problems found on http://aperiodic.net/phil/scala/s-99/ . It seems correct Scala code is based on immutable values (val) and on recursion rather than on loops and variables in order to make parallelism safer and to avoid need to use locks.

For example, a possible solution for exercise P22 ( http://aperiodic.net/phil/scala/s-99/p22.scala ) is :

// Recursive.
def rangeRecursive(start: Int, end: Int): List[Int] =
if (end < start) Nil
else start :: rangeRecursive(start + 1, end)

Of course this code is compact and looks smart but, of course, if the number of recursion is high, you’ll face a StackOverflow error (rangeRecusrsive(1,10000) for example with no JVM tuning). If you look at the source of the built in List.range (https://github.com/scala/scala/blob/v2.9.2/src/library/scala/collection/immutable/List.scala#L1), you’ll see that loops and vars are used.

My question is how to manage the influence of the Scala learning stuff which is promoting vals and recursion knowing that such code can break due to the number of recursion?

Answer 1

The nice thing about Scala is that you can easy your way into it. Starting out, you can write loops, and do more with recursion as you grow more comfortable with the language. You can’t do this with the more ‘pure’ functional languages such as Clojure or Haskell. In other words, you can get comfortable with immutability and val, and move on to recursion later.

When you do start with recursion, you should look up tail call recursion. If the recursive call is the last call in the function, the Scala compiler will optimize this into a loop in bytecode. That way, you won’t get StackOverflowErrors. Also, if you add the @tailrec annotation to your recursive function, the compiler will warn you if your function is not tail call recursive.

For example, the function in your question is not tail call recursive. It looks like the call to rangeRecursive is the last one in the function, but when this call returns, it still has to append start to the result of the call. Therefore, it cannot be tail call recursive: it still has to do work when the call returns.