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

Question

我是一名中级 Haskell 程序员，在严格的 FP 和非 FP 语言方面拥有大量经验。我的大多数 Haskell 代码都分析中等大小的数据集（10^6..10^9 东西），所以懒惰总是潜伏着。我对 thunk、WHNF、模式匹配和共享有相当好的理解，并且我已经能够使用 bang 模式和 seq 修复泄漏，但是这种配置文件和祈祷的方法让人感觉肮脏和错误。

我想知道有经验的 Haskell 程序员是如何在设计时处理懒惰的。我不是在问简单的项目，比如 Data.ByteString.Lazy 或 foldl';相反，我想知道您如何看待导致运行时内存问题和棘手调试的低级惰性机制。

您如何看待设计时的 thunk、模式匹配和共享？

您使用哪些设计模式和惯用语来避免泄漏？

你是如何学习这些模式和习语的，你有一些好的参考吗？

如何避免过早优化非泄漏非问题？

（2014-05-15 修订时间预算）：

您是否将大量的项目时间用于查找和修复内存问题？

或者，您的设计技能是否通常会规避内存问题，并且您会在开发周期的早期获得预期的内存消耗？

Answer 1

我认为“严格性泄漏”的大部分问题都是因为人们没有一个好的概念模型。没有良好概念模型的 Haskeler 倾向于拥有并传播“越严格越好”的迷信。也许这种直觉来自他们玩弄小例子和紧密循环的结果。但这是不正确的。在正确的时间偷懒与在正确的时间严格同样重要。

数据类型有两大阵营，通常称为“数据”和“余数据”。尊重每个人的模式至关重要。

• 产生“数据”（Int、ByteString、...）的操作必须强制靠近它们发生的位置。如果我向累加器添加一个数字，我会小心确保在添加另一个数字之前它会被强制执行。在这里，对惰性的良好理解非常重要，尤其是它的条件性质（即，严格性命题不采用“X 被评估”的形式，而是“当 Y 被评估，所以是X")。
• 产生和使用“codata”（大部分时间列出、树、大多数其他递归类型）的操作必须以增量方式进行。通常 codata -> codata 转换应该为它们消耗的每一位信息产生一些信息（模跳过，如filter）。 codata 的另一个重要部分是尽可能线性地使用它——即，只使用列表的尾部一次；只使用一棵树的每个分支一次。这可确保 GC 可以在使用碎片时收集碎片。

当您拥有包含数据的 codata 时，需要特别注意。例如。 iterate (+1) 0 !! 1000 在评估它之前最终会产生一个大小为 1000 的 thunk。您需要再次考虑条件严格性——防止这种情况的方法是确保 当 使用列表的一个 cons 时，会添加其元素。 iterate 违反了这一点，所以我们需要一个更好的版本。

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

当您开始编写内容时，当然很难判断何时会发生不良情况。一般来说，很难使高效的数据结构/函数在数据和余数据上同样有效，重要的是要记住哪个是哪个（即使在不能保证的多态环境中，你也应该记住一个并尝试尊重它）。

分享很棘手，我想我主要是根据具体情况来处理它。因为它很棘手，所以我尽量保持本地化，一般不向模块用户公开大型数据结构。这通常可以通过暴露组合子来生成有问题的东西，然后一次性生产和消费它（单子上的共密度变换就是一个例子）。

我的设计目标是让每个函数都尊重我的类型的数据/余数据模式。我通常可以击中它（尽管有时它需要一些深思熟虑 - 这些年来它已经变得很自然），而且我很少遇到泄漏问题。但我并不认为这很容易——它需要使用规范库和语言模式的经验。这些决定不是孤立地做出的，一切都必须立即正确才能正常工作。一种调音不佳的乐器可能会毁掉整个音乐会（这就是为什么“随机扰动优化”几乎无法解决这类问题的原因）。

Apfelmus 的Space Invariants 文章有助于进一步发展您的空间/thunk 直觉。另请参阅下面 Edward Kmett 的评论。