[haskell-cafe] Monad and kinds

[Jake Mcarthur]

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

> On 9/4/08, Jake Mcarthur <jake.mcarthur at gmail.com> 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