Re: [haskell-cafe] Monad and kinds

On Sep 5, 2008, at 12:45 AM, Tim Chevalier wrote:

On 9/4/08, Jake Mcarthur wrote:

...

Two lazy algorithms tend to compose well and result in a lazy algorithm. A lazy algorithm can compose with a strict algorithm in two different ways. One way is for the lazy algorithm to control the strict algorithm, in which case the strict algorithm is either invoked or not invoked, resulting in a lazy algorithm. The other way is for the strict algorithm to control the lazy algorithm, in which case the strict algorithm requests the data it needs from the lazy algorithm as it needs it, resulting in a strict algorithm. Finally, two strict algorithms may also compose, which results in a strict algorithm.

No matter how you slice it, none of the above scenarios are necessarily bad. Each of the four permutations of laziness and strictness for two composed algorithms are necessary for different situations. Laziness and strictness work in tandem with each other to construct whole programs.

You say lazy algorithms are good because they compose well. In Haskell, does an algorithm that operates on data structures that have strict components have that property?

The algorithm itself can still be lazy in that it might not evaluate the strict data structures at all, and thus can still have that property. However, I did not mean to necessarily emphasize the composability of lazy functions over the composability of strict functions. Both, theoretically, can compose equally well. Composition for laziness and strictness just mean slightly different things as they pertain to control flow and data flow.

...

We Haskellers like laziness by default because we find that it encourages us to consider laziness to solve our problems more often than in call-by-need languages, not because it is somehow "superior" to strictness. That is the strongest argument I can think of to be made in favor of lazy-by-default.

So you don't believe that laziness is superior to strictness, or versa; I don't, either. But you do say it's good to be encouraged to use laziness more often. Why? You mention compositionality above as a possible reason, in reply to which, see above.

Mostly because, at least in this part of history, it is easy in many languages to forget about lazy evaluation altogether. I don't think it's a matter of encouraging laziness _over_ strictness, as they are both beneficial, just a matter encouraging the programmer to _think_ in terms of laziness and strictness more often. - Jake McArthur