Are phlegmatic programmers mostly lazy or rather eager?

While designing Babel-17 I stumbled, of course, over the question what rôle lazy evaluation has in Babel-17. Is lazy evaluation the default case, just as in Haskell? Or should eager/strict evaluation be the standard mode of evaluation, just like in Standard ML?

I already sort of had made up my mind that I would root for strict evaluation, and that lazy evaluation will only survive in the way object messaging works. This point of view is also taken by the V0.1 reference implementation of Babel-17.

But is it  phlegmatic to choose strictness over laziness?  Only if this choice is based on convincing arguments. So I again digged into the evaluation order jungle, read “lamba the ultimate” posts, watched Simon Peyton Jones videos, looked at Scalas “lazy vals” and found interesting papers about lazy and strict and “lenient” evaluation orders.

Here are the arguments often given in favor of lazy evaluation:

  1. Lazy evaluation terminates for expressions that would just diverge if evaluated strictly.
  2. Lazy evaluation gives you infinite data structures.
  3. Lazy evaluation and concurrency are a great match.
  4. Lazy evaluation lets you be imprecise about the order expressions should be evaluated, as long as there is a sensible order.
  5. Lazy evaluation is “more mathematical” than strict evaluation.
  6. Laziness keeps you pure. If you use lazy evaluation, effects are difficult to deal with, because the order in which these effects manifest is not clear; therefore you will not allow side effects at all, keeping your language pure.
  7. You need laziness to define your own custom control structures.
  8. Lazy evaluation can be much better performing than strict evaluation because expressions which do not need evaluation will not be evaluated, thereby saving the time that these useless evaluations would take.

Argument 6 seems to be rather an argument against laziness in Babel-17 because Babel-17 is supposed to support effects, in particular exceptions. Argument 3 is just not true, as it is purity which is a good fit for concurrency. Laziness is rather a handicap for concurrency, as eager evaluation of expressions in parallel might lead to non-termination for certain expressions which terminate when evaluated lazily. And while argument 8 is true in principle it is a fact that actually existing strict languages like OCaml perform much better than lazy languages like Haskell.

But arguments 1, 2, 4, 5 and 7 are truly heavy-weight arguments when pitched to a phlegmatic programmer. And although strictness and concurrency are a better match than laziness and concurrency, it is purity that is most important for concurrency, not evaluation order. So why not just use lazy evaluation in Babel-17 and forget about strict evaluation?

These are the reasons:

  • Strict evaluation is sufficient for the overwhelming majority of programs. Even programs which do need lazy evaluation do so only in a few easy to identify spots and can be evaluated strictly in the remaining majority of the program.
  • Strict evaluation can be implemented more efficiently than lazy evaluation; at least so seems practical evidence to suggest.
  • The space/time consumption of lazy programs is (much) harder to understand than the consumption of strict programs. Remember, as phlegmatic programmers we not only want to create stuff, we also want to understand it.

Here is a good example of how lazy evaluation is counter-intuitive when it comes to space consumption:

def sumlist' [] acc = acc
def sumlist' (x:xs) acc = sumlist' xs (x+acc)
def sumlist xs = sumlist' xs 0

The above code uses the well-known accumulator technique to make folding over a list tail-recursive. But beware! Lazily evaluated, the accumulator will eventually take as much space as the original list you want to sum up.

So the decision regarding evaluation order in Babel-17 is as follows: Babel-17 is strict by default. But because laziness can be so useful, it will be possible to introduce laziness in those spots where it is needed. More on this in a later post.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: