On Sep 5, 2008, at 12:45 AM, Tim Chevalier wrote:
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?
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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
