On Tue, Dec 22, 2015 at 7:24 PM, Oleg <oleg@okmij.org> wrote:

Let us take a step back. The article on my web page noted the great
difficulty of writing AI search program in Haskell because the search
tree is evaluated lazily: whenever a node is evaluated, its result is
memoized for further use. That is precisely the wrong thing to do for
such problems. Again, this problem is precisely of lazy evaluation (as
defined in the book below). The obvious way to avoid memoization was
to introduce thunks -- which didn't work. The article then developed a
more involved solution. Yes, -no-full-laziness would have worked just
as well. However, the solution in the article works on the
case-by-case basis whereas -no-full-laziness affects the whole
compilation unit. It is for that reason that I pointed out the article
in this discussion.

Dear Oleg: First you paint with a wide brush that laziness is "precisely the wrong thing to do for such problems."

Then you implicitly acknowledge that there are different levels of laziness, namely that non-full-laziness is less lazy than full laziness. Call them laziness Levels 1 and 2, respectively

Finally, you cite your local solution as an improvement to the blunt one of throttling the whole module to mere laziness Level 1.

Therefore, the clever Level 1 localization is an improvement only if laziness Level 2 is useful in other parts of the module, yes?

How can laziness be so bad, as the shrillness of your emails convey, if a laziness Level /2/ -- never mind Level 1 -- is actually useful elsewhere in your code?

Notwithstanding your eagerness to warn of the pitfalls of laziness, your true position on laziness is undoubtedly nuanced in a manner that befits your discernment and decades of programming experience.

Unfortunately, here you don't express that nuance clearly, and we are left in the dark.

-- Kim-Ee