On Sep 4, 2008, at 11:40 PM, Tim Chevalier wrote:
But why not write your types like: data Stream a = Cons a <Stream a> data Vector3 a = Vector3 a a a in a hypothetical call-by-value language where the <> annotation denotes a lazily evaluated data structure? Does it matter? If it does, then why? If it doesn't, then what would you conclude about whether a language should encourage laziness or strictness?
It doesn't matter, and I don't think it says anything about whether we should encourage lazy-by-default or strict-by-default. 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. 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.
both laziness and strictness exist in strict languages, as well. What if, as a thought experiment, you tried substituting "laziness" for "strictness" in that paragraph of your essay?
I think the same points would apply, honestly. Do you believe they would change in some way? - Jake McArthur