haskell - 惰性评估如何允许更大的模块化？

Question

在他的文章“Why Functional Programming Matters”中，John Hughes 认为“懒惰评估可能是函数式程序员技能中最强大的模块化工具。”为此，他提供了如下示例:

假设您有两个函数，“infiniteLoop”和“terminationCondition”。您可以执行以下操作:

terminationCondition(infiniteLoop input)

惰性求值，用 Hughes 的话来说“允许将终止条件与循环体分开”。这绝对是真的，因为这里使用惰性求值的“terminationCondition”意味着可以在循环外定义这个条件——当终止条件停止请求数据时，infiniteLoop 将停止执行。

但是高阶函数不能实现如下相同的事情吗？

infiniteLoop(input, terminationCondition)

惰性求值如何在这里提供高阶函数没有提供的模块化？

Answer 1

是的，您可以使用传入的终止检查，但要实现这一点，请使用 infiniteLoop 的作者将不得不预见想要以这种条件终止循环的可能性，并将对终止条件的调用硬连接到它们的函数中。

而且即使特定条件可以作为函数传入，它的“形状”也是infiniteLoop作者预先确定的。 .如果他们给我一个在每个元素上调用的终止条件“槽”，但我需要访问最后几个元素来检查某种收敛条件怎么办？也许对于一个简单的序列生成器，您可以提出“最通用的”终止条件类型，但是如何做到这一点并保持高效和易于使用并不明显。到目前为止，我是否重复将整个序列传递到终止条件中，以防它正在检查？我是否强制我的调用者将他们简单的终止条件包装在一个更复杂的包中，以便它们适合最通用的条件类型？

调用者当然必须确切地知道如何调用终止条件才能提供正确的条件。这可能相当依赖于这个特定的实现。如果他们切换到 infiniteLoop 的不同实现由另一个第三方编写，终止条件使用完全相同的设计的可能性有多大？带着懒惰infiniteLoop ，我可以删除任何应该产生相同序列的实现。

如果 infiniteLoop不是一个简单的序列生成器，而是实际上生成了一个更复杂的无限数据结构，比如一棵树？如果树的所有分支都是独立递归生成的(想想像国际象棋这样的游戏的移动树)，基于迄今为止生成的信息的各种条件，在不同深度切割不同的分支可能是有意义的。

如果原作者没有准备(无论是专门针对我的用例还是针对足够通用的用例类)，我就不走运了。作者懒人infiniteLoop可以顺其自然地写出来，让每个来电者懒洋洋地探索他们想要的东西；双方都不必了解对方太多。

此外，如果停止懒惰地探索无限输出的决定实际上与(并依赖于)调用者对该输出进行的计算交织在一起呢？再想想棋步树；我想探索树的一个分支多远很容易取决于我对我在树的其他分支中找到的最佳选择的评估。所以要么我做两次遍历和计算(一次在终止条件下返回一个标志告诉 infinteLoop 停止，然后再次使用有限输出，这样我才能真正得到我的结果)，或者 infiniteLoop 的作者不仅要准备终止条件，还要准备返回输出的复杂函数(以便我可以将整个计算插入“终止条件”)。

在极端情况下，我可以探索输出并计算一些结果，将它们显示给用户并获得输入，然后继续探索数据结构(不根据用户的输入记忆 infiniteLoop)。懒人原作者infiniteLoop不需要知道我会想到做这样的事情，它仍然有效。如果我们通过类型系统强制执行纯度，那么使用传入的终止条件方法是不可能的，除非整个 infiniteLoop如果终止条件需要，允许有副作用(比如通过给整个事物一个 monadic 接口(interface))。

简而言之，通过使用严格的 infiniteLoop 来获得与惰性求值相同的灵活性。使用高阶函数来控制它对于 infiniteLoop 的作者来说可能是大量额外的复杂性。及其调用者(除非暴露了各种更简单的包装器，并且其中之一与调用者的用例相匹配)。延迟评估可以让生产者和消费者几乎完全解耦，同时仍然让消费者能够控制生产者产生多少输出。你可以用这种方式做的一切你都可以用额外的函数参数来做，但是它需要生产者和消费者就控制功能如何工作的协议(protocol)达成基本一致；并且该协议(protocol)几乎总是专门针对手头的用例(将消费者和生产者捆绑在一起)或非常复杂以完全通用，以至于生产者和消费者都与该协议(protocol)相关联，而该协议(protocol)不太可能重新创建在别处，所以他们仍然联系在一起。