From 61ba31b6681e4d932510161d9416635e73060aa3 Mon Sep 17 00:00:00 2001 From: Tony Hannan Date: Tue, 19 Jul 2011 10:59:38 -0400 Subject: [PATCH] small edit to article --- doc/Article2.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/Article2.md b/doc/Article2.md index b7fd375..4c69f58 100644 --- a/doc/Article2.md +++ b/doc/Article2.md @@ -36,7 +36,7 @@ Haskell expressions are [lazily evaluated](http://en.wikipedia.org/wiki/Lazy_eva cond bool a b = case bool of True -> a; False -> b x = cond True 1 (2 `div` 0) -`x` evaluates to 1 instead of failing on divide-by-zero because the last argument is not evaluated in this case. Lazy evaluation facilitates user-defined control structures, like `cond` above. It also enables infinite data structures, like `ones = 1 : ones` (infinite list of 1's) or `[1,2..]` (infinite sequence), because later elements are only created on demand. Finally, lazy evaluation facilitates modularity because you can separate functionality knowing that an inner operation will only proceed when its outer operation demands it. Intermediate data structures (eg. lists) won't be built in full then later consumed, instead each element will be built on demand and immediately consumed thus using constant space. This behavior is similar to piping programs together in Unix. To get similar behavior in an eager language, you could use an imperative generator for intermediate operations, but this is more complex, not pervasive, and not pure. +`x` evaluates to 1 instead of failing on divide-by-zero because the last argument is not used in this case. Lazy evaluation facilitates user-defined control structures, like `cond` above. It also enables infinite data structures, like `ones = 1 : ones` (infinite list of 1's) or `[1,2..]` (infinite sequence), because later elements are only created on demand. Finally, lazy evaluation facilitates modularity because you can separate functionality knowing that an inner operation will only proceed when its outer operation demands it. Intermediate data structures (eg. lists) won't be built in full then later consumed, instead each element will be built on demand and immediately consumed thus using constant space. This behavior is similar to piping programs together in Unix. However, a drawback of lazy evaluation (and thus Haskell) is hard-to-predict space usage. For example, we know the above `reduce` function requires (stack) space linear to the size of the list, but what about its [tail recursive](http://en.wikipedia.org/wiki/Tail_recursion) version, which uses constant stack space.