On 9/4/08, Jake Mcarthur <[EMAIL PROTECTED]> 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? > 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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe