我是 Haskell 的新手，閱讀教程我發現了類似的東西
由于 Haskell 的懶惰，即使您多次在串列上映射某些內容并對其進行多次過濾，它也只會通過串列一次。
這是我的簡單愚蠢的例子： x = map foo (map foo [1,2]) where foo p = p * 2
現在，我想到了兩個問題。
- 為什么要歸功于懶惰？我知道懶惰意味著它不會評估運算式直到它必須但是......它如何強制迭代串列一次而不是宣告的地圖/過濾器數量？
- 如何驗證它只迭代一次？
- 額外的問題 - 我知道副作用是??但是......如果我可以列印一些東西來除錯，那就太好了，例如
foo p =
let printResult = print "Some helpful message"
in p * 2
uj5u.com熱心網友回復：
為什么要歸功于懶惰？我知道懶惰意味著它不會評估運算式直到它必須但是......它如何強制迭代串列一次而不是宣告的地圖/過濾器數量？
如果您只對串列的第一個元素感興趣，map則不會評估串列的其余部分。
想象一下，您有興趣評估map foo (map foo [1,2])頭部范式。然后它將因此呼叫map foo (map foo [1,2]).
map :: (a -> b) -> [a] -> [b]被實作為[SRC] ：
map :: (a -> b) -> [a] -> [b] map _ [] = [] map f (x:xs) = f x : map f xs
因此，它會將子運算式計算map foo [1,2]為正常形式：它必須知道外部項是空串列資料建構式[]還是“cons” (_:_)。
所以它將評估第二個地圖，但僅限于外部資料建構式。這意味著它將看到串列[1,2]不為空，因此它將產生foo 1 : map foo [2]. 它不會評估foo 1，因為那也不是必需的。
由于我們現在知道子運算式有一個“cons”作為資料建構式，因此外部 map 函式將回傳foo (foo 1) : map foo (map foo [2])。因此，它將原始串列的“游標”向前移動了一步，但它不會列舉整個串列，也不會評估foo元素上的函式。
如果我們想列印head例如，就像print (head (map foo (map foo [1,2])))，這意味著head將被評估，并且head (foo (foo 1) : map foo (map foo [2]))只會回傳foo (foo 1)。這將再次無法評估foo (foo 1)。現在print需要評估第一項，因為它應該將它列印到輸出通道，這意味著它評估foo (foo 1). 為了求值foo (foo 1)，它首先必須求值foo 1，因為這是強制求值乘法所必需的，因此foo 1求值為2，foo 2求值為4。
但是我們因此通過不評估整個串列或foo (foo …)其他元素的部分節省了很多周期。
如何驗證它只迭代一次？
有像vizualize-cbn[GitHub]和ghc-viz[Hackage]這樣的工具可以幫助可視化 Haskell 如何處理惰性。人們可以看到對一個元素的評估如何導致其他元素的可視化，這有助于理解遞回模式。
額外的問題 - 我知道副作用是??但是......如果我可以列印一些東西來除錯，那就太好了，例如
可以使用trace :: String -> a -> a來列印訊息，例如：
import Debug.Trace(trace)
foo p = trace "evaluated foo" (p * 2)如果您然后評估print (head (map foo (map foo [1,2])))，您會看到它只評估foo兩次，而不是四次。的確：
ghci> import Debug.Trace(trace)
ghci> foo p = trace "evaluated foo" (p * 2)
ghci> print (head (map foo (map foo [1,2])))
evaluated foo
evaluated foo
4
uj5u.com熱心網友回復：
未明確覆寫對方的回答一點，是有是在偷懶的意思是“即使你一些映射在一個串列上幾次，過濾幾次，它只會傳過來的名單，一旦”感。
讓我們看看當我們評估時會發生什么，map foo (map foo [1, 2, 3])而不是head像 Willem Van Onsem 的答案中那樣消費者，而是說我們正在print評估它，所以我們需要評估整個事情。
雖然我不想print詳細跟蹤實際的評估，所以讓我們假設我們有一個特殊用途print的串列，看起來像這樣（這putStr是一個原始的）：
print :: Show a => [a] -> IO ()
print [] = putStr "[]"
print (x : xs) = putStr "[" >> putStr (show x) >> print_rest xs
where print_rest [] = putStr "]"
print_rest (x : xs) = putStr ", " >> putStr (show x) >> print_rest xs
當然，我們有：
map :: (a -> b) -> [a] -> [b]
map _ [] = []
map f (x:xs) = f x : map f xs
和：
foo p = p * 2
所以，我們開始：
print (map foo (map foo [1, 2, 3]))
這當然是真的：1
print (map foo (map foo (1 : 2 : 3 : []) ))
print需要模式匹配它的引數，這需要強制外部map. map反過來，外部首先需要知道它的引數是否為空，從而強制內部映射呼叫。內部映射還需要對其引數進行模式匹配，但這是一個非空的具體串列。所以現在我們可以回傳模式匹配堆疊并得到這個：
print (map foo (map foo (1 : 2 : 3 : []) ))
print (map foo (foo 1 : map foo (2 : 3 : []) ))
print (foo (foo 1) : map foo (map foo (2 : 3 : []) ))
putStr "[" >> putStr (show (foo (foo 1))) >> print_rest (map foo (map foo (2 : 3 : []) ))
現在我們有了IO驅動程式可以使用的東西（一個putStr電話）。所以它可以假設，導致控制臺輸出顯示：
[
我們留下了運算式：
putStr (show (foo (foo 1))) >> print_rest (map foo (map foo (2 : 3 : []) ))
其中有另一個putStr在頭; 這個只需要給力show (foo (foo 1))。show具有力foo (foo 1)，其具有強制foo 1到2; 那么外層foo可以生產，4所以show可以生產"4"。
putStr "4" >> print_rest (map foo (map foo (2 : 3 : []) ))
讓IO我們現在在控制臺輸出上也使用它：
[4
并留下這個運算式：
print_rest (map foo (map foo (2 : 3 : []) ))
通過與上面相同的程序，我們可以去：
print_rest (map foo (map foo (2 : 3 : []) ))
print_rest (map foo (foo 2 : map foo (3 : []) ))
print_rest (foo (foo 2) : map foo (map foo (3 : []) ))
putStr "," >> putStr (show (foo (foo 2))) >> print_rest (map foo (map foo (3 : []) ))
putStr "," >> putStr (show (foo 4)) >> print_rest (map foo (map foo (3 : []) ))
putStr "," >> putStr (show 8) >> print_rest (map foo (map foo (3 : []) ))
putStr "," >> putStr "8" >> print_rest (map foo (map foo (3 : []) ))
然后IO驅動程式可以使用putStr呼叫，所以我們可以看到：
[4, 8
并留下要評估的運算式：
print_rest (map foo (map foo (3 : []) ))
變成（現在跳過一些步驟）：
putStr "," >> putStr (show (foo (foo 3))) >> print_rest (map foo (map foo [] ))
putStr "," >> putStr "12" >> print_rest (map foo (map foo [] ))
IO 它是不是很神奇，以便我們可以在控制臺上看到：
[4, 8, 12
最后殘差的print_rest (map foo (map foo [] ))計算非常簡單，putStr "]"所以我們終于可以看到：
[4, 8, 12]
現在，讓我們反思一下發生了什么。
Lazy evaluation means we don't evaluate anything until it's needed, and the "need" ultimately comes from the IO driver needing to evaluate things until it has concrete primitives with fully evaluated arguments so that it can actually do something. That's why I chose the order that I did to evaluate things.
If you look over it you should notice that at no point did we ever produce an expression like map foo [2, 4, 6]. We evaluated both of the foo calls on the first element of the list before any of the mapping or printing even pattern matched to see if there was a second element of the list. This also means that the first element of the list (and both results of fooing it) became unreferenced and could be reclaimed by the garbage collector before the second element of the list was examined. And then the second element of the list was fully processed before the third was examined, too.
This is the sense in which laziness evaluates nested maps, filters, etc with only a single traversal of the base list. Sometimes this can result in large efficiency gains compared to an eager evaluation of the same nested maps, filters, etc. For example, if the base list was not a small concrete list like [1, 2, 3] but rather an expression that would lazily produce a very large (even infinite!) list, then our whole "multi-pass" sequence of maps could operate with only enough memory for one element at a time, rather than needing to produce the full base sequence, and then produce the full sequence at the next stage, and so on for each stage. It also means that we produce and consume all the intermediate stages of one value immediately, increasing the chance that we are working within the CPU cache or the shortest-lived most-efficient generation of the garbage collector's heap.
However, if you look very carefully, you'll note that even though we "only traversed the list once", we still had exactly the same : constructor applications that we would have had if we had fully evaluated map foo [1, 2, 3] to [2, 4, 6] and then traversed that. We still allocated a constructor cell for foo 1 : _, then immediately consumed it and allocated foo 2 : _.
So in another sense "laziness means we only traverse the list once" is not true. When we do end up using the whole list (as opposed to using head or take to only inspect some of it), then lazy evaluation results in exactly the same work (meaning allocations and pattern matches) as if we did evaluate each stage in its entirety and then traverse the result for the next stage. We've rearranged the work, and the order produced by lazy evaluation is frequently better, but we haven't fundamentally changed the amount of work we have to do. The intermediate lists are still there in some sense, even if they're never present in memory all at once.
Fortunately GHC has many other optimizations that come into play to avoid actually creating the intermediate list cells (or indeed the base list!), in many cases. For example, GHC can recognise that map foo (map bar xs) is equivalent to map (foo . bar) xs, which has no intermediate list to traverse or allocate whether we're evaluating lazily or eagerly. Particularly simple cases like the example I've used would be heavily inlined, and probably end up essentially compiled to just directly print [4, 8, 12] without allocating or evaluating anything.
TLDR：從某種意義上說，當您鏈接映射和過濾器等函式時，惰性求值確實避免了重復遍歷中間串列。因此 OP 中的參考很可能是準確的（取決于其作者的意圖），但存在重要的細微差別，重要的是不要過度推銷它。
當需要全部結果時，那些遍歷的所有作業仍然完成；惰性求值只是重新排列作業完成的順序。如果它允許您顯著減少中間結果消耗的記憶體，這仍然是一個巨大的勝利，因為它們現在可能不必一次全部出現在記憶體中。
1請記住，串列的方括號語法只是人們寫出一個序列的好方法，該序列實際上在記憶體中表示為:建構式的一系列嵌套應用程式，由建構式終止[]。[1, 2, 3]is 1 : (2 : (3 : []))，我們不需要那些內括號，因為:建構式是中綴和右結合的，所以我們可以寫1 : 2 : 3 : [].
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/387004.html