问经验丰富的Haskell开发人员是如何在设计时处理懒惰的？

EN

我认为大多数“严格泄漏”的问题发生是因为人们没有一个好的概念模型。没有一个好的概念模型的Haskellers倾向于并传播一种迷信，即更加严格是更好的。也许这种直觉来自于他们通过玩弄小例子而产生的结果&紧密的循环。但这是不正确的。在适当的时候懒惰和在正确的时间严格要求同样重要。

有两类数据类型，通常称为“数据”和“共同数据”。必须尊重每个人的模式。

• 生成“数据”的操作(Int，ByteString，.)必须被迫靠近它们发生的地方。如果我向累加器添加了一个数字，那么在添加另一个累加器之前，要确保它是强制的。在这里，很好地理解懒惰是非常重要的，特别是它的条件性质(即严格性命题不采取"X获取评估“的形式，而是”当Y被计算时，X也是“)。
• 生成和使用"codata“(列出大多数时间、树、大多数其他递归类型)的操作必须以增量方式完成。通常，codata -> codata转换应该为它们使用的每一位信息生成一些信息(模块跳过就像filter一样)。codata的另一个重要部分是尽可能线性地使用它--也就是精确地使用列表的尾部一次；使用树的每个分支精确地使用一次。这确保GC可以在使用时收集碎片。

当你有包含数据的共同数据时，事情需要特别小心。例如，iterate (+1) 0 !! 1000最终会在评估它之前产生一个1000磅的大小。您需要再次考虑条件严格性--防止这种情况的方法是确保当列表的一个缺点被消耗时，就会添加它的元素。iterate违反了这一点，所以我们需要一个更好的版本。

iterate' :: (a -> a) -> a -> [a]
iterate' f x = x : (x `seq` iterate' f (f x))

当然，当你开始写东西的时候，很难判断什么时候会发生不好的事情。通常，很难使高效的数据结构/函数在数据和协同数据上同样工作良好，而且重要的是要记住哪一个(即使在多态设置中，在没有保证的情况下，您应该考虑并努力尊重它)。

分享是一个棘手的问题，我认为我主要是在逐个案例的基础上来处理这个问题。因为这很棘手，所以我尽量将其本地化，选择不向一般的模块用户公开大型数据结构。这通常可以通过公开用于生成所述事物的组合子来完成，然后一次产生和使用所有这些(单子上的共密度转换就是一个例子)。

我的设计目标是让每个函数都尊重我的类型的数据/协数据模式。我通常能做到这一点(虽然有时需要一些深思熟虑-这些年来，它已经变得很自然了)，而且我很少有泄漏问题。但我并不认为这很容易--它需要掌握规范库和语言模式的经验。这些决定不是孤立地作出的，一切都必须立即正确，才能顺利运作。一台调得不好的乐器会毁了整个音乐会(这就是为什么“随机扰动优化”几乎从不适用于这类问题的原因)。

Apfelmus的空间不变量文章有助于进一步发展您的空间/直觉。也见下面爱德华·克米特的评论。