Simon Peyton Jones

it would be a very, very big tree.

In OCaml, it would be too big, because first of all, I compute the tree, and then I'd start deciding what move to do.

It couldn't possibly do that, because the tree of all possible moves has more nodes in it than the number of protons in the universe.

So let's not do that.

If instead you could build the tree, oh, having got this tree, supposing you had it, you could then walk over the tree saying, oh, let me do some minimaxing and say, oh, this looks like a good position.

Let me go this way.

I could explore the tree, right?

Now then, so in OCaml then, you would have to put the tree generation and the tree exploration in one function, right?

In Haskell, with lazy evaluation, you can generate an infinite tree

And then the explorer that prunes the tree and explores just the bits of it that are necessary is completely modularly separated.

I can build a different generator and a different pruner.

They're just completely separate programs.

So lazy evaluation is very powerful glue that lets you glue together two programs that you'd like to be distinct.

Strict evaluation forces you to merge them together.

Every strict language, every, you know, serious strict language has lazy evaluation in it.

They're called iterators or generators.

And so does OCaml, right?

But in Haskell, that's the default.

Instead, in Haskell, so this is a bit like, again, the two are converging on the middle.

Haskell, lazy by default, but you can make things strict.