渴望与懒惰的哈斯克尔。 Eager 语言中可能存在无限列表？答案

【问题标题】：Eager versus Lazy Haskell. Infinite lists possible in Eager languages?渴望与懒惰的哈斯克尔。 Eager 语言中可能存在无限列表？
【发布时间】：2012-01-30 08:40:24
【问题描述】：

显然，可以实现 Haskell 以使其在不改变语言语义的情况下急切地求值。如果是这样，无限数据结构是如何处理的？

http://csg.csail.mit.edu/pubs/haskell.html

因此，大量时间用于创建和销毁暂停的计算（thunk）。很多时候，这些计算非常简单，以至于评估它们同样容易。 Faxen 和其他人已经使用静态分析来揭示这种渴望的机会。相反，我们建议在任何地方都使用渴望，同时使用允许我们在程序过于渴望时恢复的机制。

关键是“如果我们的程序过于急切，我们有恢复机制”。这些机制是什么？它们如何允许无限的数据结构和惰性求值的其他方面，我一直认为这些方面在热切的语言中是不可能的？

【问题讨论】：

您链接到的页面似乎提供了机制的概述。你有什么具体要澄清的吗？
是的，当我继续阅读时，我才意识到这一点。应该先阅读全文。我觉得自己像个傻瓜：p 当有人犯这样的错误时，SO 程序是什么？我应该删除问题吗？
关闭问题通常没问题。无论如何，ehird 的答案很有用，最好在保留信息方面犯错。
我认为这样的问题很有价值，因为链接的页面很长并且涉及很多细节；对其工作原理的简短总结是一件好事。
您可以用一种急切的语言创建“无限”的数据结构。举一个愚蠢的例子，您可以将编译为 C 的 Haskell 代码视为 C 程序。如果 Haskell 程序包含无限结构，那么 C 程序也是如此。

标签： haskell lazy-evaluation infinite eager

【解决方案1】：

这并不完全正确：您可以急切地评估 Haskell 术语如果您能证明它们不会发散。

例如，当你看到f x时，你可以先执行最多1000步x（如果达到WHNF（弱头范式）或错误则停止），然后通过它到 f - 语义被保留，但如果您认为 x 将被评估，那么您可以安排提前发生这种情况作为优化。

如果x = fix id，1000 步无处可去后就放弃了。如果x = undefined，会报错并放弃（恢复原来的thunk并传递给f）。以此类推。

如果是x = [1..]，那么它可能最终将其减少到1 : 2 : 3 : ... : 999 : 1000 : [1001..]，达到极限，然后停在那里，将结果传递给f。

基本上：要么证明一个表达式不能发散，要么限制求值，即使它发散，事情也会终止。语义没有变化，性能可能有很大提升。

当然，缺点是如果 x 是一些非常昂贵的计算，而 f 只使用了一半，那么你将花费 1,000 个缩减步骤来浪费时间.在[1..] 的情况下，您最终可能会使用大量内存来存储列表；如果 f 一次处理列表一个元素，每次都扔掉头部，那么你会浪费内存。这就是为什么它很棘手:)

您最初链接的页面更详细地介绍了所使用的具体技术。

【讨论】：