How pure and lazy can Scala be?

Question

This is just one of those "I was wondering..." questions.

Scala has immutable data structures and (optional) lazy vals etc.

How close can a Scala program be to one that is fully pure (in a functional programming sense) and fully lazy (or as Ingo points out, can it be sufficiently non-strict)? What values are unavoidably mutable and what evaluation unavoidably greedy?

Answer 1

Regarding lazyness - currently, passing a parameter to a method is by default strict:

def square(a: Int) = a * a 

but you use call-by-name parameters:

def square(a: =>Int) = a * a 

but this is not lazy in the sense that it computes the value only once when needed:

scala> square({println("calculating");5}) calculating calculating res0: Int = 25 

There's been some work into adding lazy method parameters, but it hasn't been integrated yet (the below declaration should print "calculating" from above only once):

def square(lazy a: Int) = a * a 

This is one piece that is missing, although you could simulate it with a local lazy val:

def square(ap: =>Int) = {   lazy val a = ap   a * a } 

Regarding mutability - there is nothing holding you back from writing immutable data structures and avoid mutation. You can do this in Java or C as well. In fact, some immutable data structures rely on the lazy primitive to achieve better complexity bounds, but the lazy primitive can be simulated in other languages as well - at the cost of extra syntax and boilerplate.

You can always write immutable data structures, lazy computations and fully pure programs in Scala. The problem is that the Scala programming model allows writing non pure programs as well, so the type checker can't always infer some properties of the program (such as purity) which it could infer given that the programming model was more restrictive.

For example, in a language with pure expressions the a * a in the call-by-name definition above (a: =>Int) could be optimized to evaluate a only once, regardless of the call-by-name semantics. If the language allows side-effects, then such an optimization is not always applicable.