How is foldl lazy?

Question

There are lots of good questions and answers about foldl, foldr, and foldl\' in Haskell.

So now I know that:
1) foldl<

Answer 1

It seems like I have to start worrying about order-of-evaluation in Haskell, if I don't want my program to crash.

In my opinion, the best options if you want your program not to crash are (ranked from better to worse in terms of yield per effort spent): 1. Give it enough resources. 2. Improve your algorithm. 3. Do micro-optimisations (one of which is foldl').

So, rather that worrying about the order of evaluation I'd rather first worry about what is to be evaluated (is foldr enough? can I do without folding that at all?). And before that, I'd increase the available stack space.

You don't limit your whole program to 8MB of RAM, do you? Why would you limit the stack space then? Just increase the stack space to 4GB and start worrying when something really hogs a lot of it (like you do with heap memory).

And to somewhat answer the question of how foldl is lazy:

foldl (\x y -> y) undefined [undefined, 8] -- evaluates to 8
foldl' (\x y -> y) undefined [undefined, 8] -- fails to evaluate

Answer 2

I'm still looking for an example where evaluating the combining function more eagerly would lead to a different result

The general rule of thumb is never, ever use foldl. Always use foldl', except when you should use foldr. I think you know enough about foldl to understand why it should be avoided.

See also: Real World Haskell > Functional Programming # Left folds, laziness, and space leaks

However, your question neglects foldr. The nifty thing about foldr is that it can produce incremental results, while foldl' needs to traverse the entire list before yielding an answer. This means that foldr's laziness allows it to work with infinite lists. There are also questions and answers that go into detail about this sort of thing.

Having brought that up, let me try to succinctly answer your questions.

1) why does reduction have to occur after all thunk-ing?

Reduction only occurs at strictness points. Performing IO, for example, is a strictness point. foldl' uses seq to add an additional strictness point that foldl does not have.

2) why isn't foldl evaluated just like foldl'? Is this just an implementation side-effect?

Because of the additional strictness point in foldl'

3) from the definition, foldl looks like a tail-recursive function to me -- how can I tell whether a function will actually be efficiently evaluated? It seems like I have to start worrying about order-of-evaluation in Haskell, if I don't want my program to crash.

You need to learn a little bit more about lazy evaluation. Lazy evaluation is not exclusive to Haskell, but Haskell is one of the very, very few languages in which laziness is the default. For a beginner, just remember to always use foldl' and you should be fine.

If laziness actually gets you into trouble someday, that is when you should probably make sure you understand laziness and Haskell's strictness points. You might say that said theoretical day is a strictness point for lazy-by-default learning.

See also: PLAI > Part III: Laziness

Answer 3

The short answer is that in foldl f, it's not necessarily the case that f is strict, so it might be too eager to reduce the thunks up front. However, in practice it usually is, so you nearly always want to be using foldl'.

I wrote a more in-depth explanation of how the evaluation order of foldl and foldl' works on another question. It's rather long but I think it should clarify things a bit for you.

Answer 4

You know, that by definition:

foldl op start (x1:x2:...:xN:[]) = ((start `op` x1) `op` x2) ...

the line in foldl that does this is:

foldl op a (x:xs) = foldl op (a `op` x) xs

You are right that this is tail recursive, but observe that the expression

(a `op` x)

is lazy and at the end of the list, a huge expression will have been build that is then reduced. The difference to foldl' is just that the expression above is forced to evaluate in every recursion, so at the end you have a value in weak head normal form.