On 9/4/08, Jake Mcarthur
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?
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. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "The future is not google-able." -- William Gibson