Haskell Heap上的求值

这是对Edward Z. Yang的Haskell Heap系列的翻译。
感谢Edward的无私奉献，允许我对这些文章进行翻译。
Edward以Creative Commons Attribution-ShareAlike 3.0 Unported License对文章进行了授权，所以译文也以此License发布。 

--------------------------------------------------------------------------------

                Haskell Heap上的求值 

原文地址为：http://blog.ezyang.com/2011/04/evaluation-on-the-haskell-heap/

第一次看到这个系列吗？那么请从头开始看。

圣诞礼物中的幽灵

在今天这篇文章中，我们简要探究一下当你打开Haskell heap中闹鬼的礼物时会发生的许多事情。除了常量和那些已经被求值的事物，Haskell heap中的所有事物基本上都是闹鬼的。因此真正的问题是幽灵在礼物上搞了什么鬼。

最简单的情形是，什么也没干！

这和礼物卡不同（译注：这指的是x=y，你打开了礼物盒子x，里面的幽灵告诉你礼物在盒子y，所以说与礼物卡不同），你必须打开下一个礼物（Haskell不允许你对一个thunk求值后，又不按照间接指示继续前进...）（译注：注意看上下的漫画，当你打开一个礼物时，幽灵告诉你礼物不在这里，在另一个地方。你要按照这个指示去下一个地方拿礼物，也就是按照指示间接而非直接地拿到礼物。如果你打开礼物/thunk后，不按照找指示做，那么Haskell是不会允许你打开/求值的。）

更常见的是，幽灵很lazy，当他被唤醒时，不得不打开别的礼物来确定你第一次拿到的礼物里面有什么。（译注：同样注意看下面的漫画，这里的幽灵指的是你打开的第二个礼物里的幽灵。）

简单的基本运算需要打开所有涉及的礼物。

但是幽灵也可能无缘无故地打开了另一个礼物...（译注：其实原因就是seq）

或者执行一些IO ...

注意，他打开的任何礼物都有可能唤醒更多的幽灵：

最终真成了幽灵狂欢节，这都是为了打开一个礼物！

打开一个礼物（thunk）可能会造成这样一个级联效应，如果你习惯了heap上的所有对象都已经被打开（求值）的话，那么这就是造成对惰性求值的计时会让你感到惊讶的原因。所以了解真相的关键是：搞清楚幽灵何时决定它需要打开一个礼物（strictness分析），以及你的礼物是否已经被打开了（amortized分析）。

上一篇：The Haskell Heap 
下一篇：IO对Haskell Heap求值