[Haskell-cafe] Preventing sharing

Kim-Ee Yeoh ky3 at atamo.com
Tue Dec 22 18:01:29 UTC 2015


On Tue, Dec 22, 2015 at 7:24 PM, Oleg <oleg at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151223/ad4dbc6b/attachment.html>


More information about the Haskell-Cafe mailing list