Functional programming 不使用'；不要以懒惰的语言结束

据

有些算法不是以一种渴望的语言结束，而是以一种懒惰的语言结束，反之亦然（我发现这是一个轻微的震惊）

前者当然是众所周知的，但后者给我的印象是，如果是真的，远远超过一个轻微的震惊

---

有人知道一种算法是以一种渴望的语言而不是一种懒惰的语言终止的吗？

我要冒险指出，任何一种算法在一个纯粹的函数式渴望环境中终止，都不会在一个纯粹的函数式懒惰环境中终止

---

正在讨论的文章没有提到这一点，评论之后是一个不符合要求的示例请求。因此，在找到一个例子之前，我会说不。

维基百科为lambda演算回答了这个问题：

关键部分是：

应用顺序不是一种规范化策略。[…]相反，所谓正常顺序是因为它总是发现一个正常化减少（如果存在）

这显示了惰性评估更强大的特性：如果有一种评估策略使特定程序终止，那么程序也会以惰性评估终止。因此，特别是严格求值（应用程序顺序）不允许任何程序在惰性求值下终止该循环

---

维基百科页面上的参考资料提供了证据。

我假设你不想修改状态？因为修改程序状态的急切调用可以，比如说终止程序，但是某种惰性调用的链接可以开始计算无限循环。对，上下文是函数编程，所以我假设在这两种情况下都是纯的。一些惰性算法不会终止，因为它们在内存中构建的惰性结构与严格的语言相比是巨大的。foldl/foldr就是一个很好的例子（请参阅）。我猜这不是你的意思！foldr的问题与懒惰毫无关系，因为同样的问题也出现在热切的语言中。这就是为什么reduce习惯用法的一个典型定义包括一个初始值或中性值，而reduce是以尾部递归的方式进行的。除了您的观点之外，还有其他原因吗？并不是说我不认为你是对的；我想你是的，但是你的回答没有任何价值。没有：），我没有提供这个猜想的正式教授。如果不是一个正式的教授会证明答案是否定的，那么“是”阵营所需要做的就是提供一个例子，我的“稻草人”论点就会失败。我的推理是，在惰性系统中，所有需要的值都将在某个阶段进行评估，因此，尽管渴望的系统可能会评估太多，例如，首先（无限列表），但惰性系统只会评估渴望的系统将评估的部分。这是我的稻草，让我看看反例。“P！=NP，如果你敢问我，请提供一个反例！”这不是数学或计算机科学问题的答案。你在这篇评论中的解释是朝着正确的方向迈出的一小步，但远没有令人信服的地方。我知道“我没有提供这个猜想的正式教授。除非正式教授会证明答案是否定的。”我评论末尾的笑脸是为了表示一个语气。我相信我是对的，但我并没有证明这一点。我希望有人开始回答“是”以及他们为什么相信这一点。这将提供一个在这个网站上讨论的框架，我们可以看到未洗的群众相信什么。我不知道是否存在人类学或心理学，但这肯定不是；）我同意你相信你所说的有帮助的原因，但你的回答只是一个断言。问题是“X是真的吗”，你的回答是“我声明X是真的”。+1！有点虎头蛇尾——我希望这不是真的对，我的理解是，事实就是如此，这就是为什么我会被一个反例稍微震惊的原因。谢谢但问题不在于表达式是否具有标准形式，而在于计算是否终止。我可能错了，但我很确定两者之间有一些令人讨厌的区别。在lambda计算的上下文中，还原为标准形式是计算的模型。在这个模型中，我很确定非终结就是找不到正规形式（因为归约序列是无限的）。但是一个懒惰的编程语言不是一个计算模型，并且缺乏lamdba演算的数学纯度。你是说所有的惰性编程语言都是正常顺序缩减的完美体现，以至于所有适用于正常顺序的数学证明都适用于所有惰性编程语言？这看起来有点像拉伸…