懒惰评估如何允许更大的模块化？

Question

在他的文章"为什么函数式程序设计很重要“中，John认为”懒散的评估可能是功能程序员最强大的模块化工具。“为此，他举了一个这样的例子：

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

terminationCondition(infiniteLoop input)

懒散的评估，用休斯的话说，“允许终止条件与循环体分开。”这是绝对正确的，因为这里使用惰性计算的" terminationCondition“意味着可以在循环之外定义这个条件--当terminationCondition停止请求数据时，infiniteLoop将停止执行。

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

infiniteLoop(input, terminationCondition)

在这里，惰性评估是如何提供高阶函数所不提供的模块化的？

Answer 1

是的，您可以使用已通过的终止检查，但要做到这一点，infiniteLoop的作者将不得不放弃使用这种条件终止循环的可能性，并将对终止条件的调用硬连接到他们的函数中。

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

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

如果infiniteLoop不是一个简单的序列生成器，而是实际上生成了一个更复杂的无限数据结构，比如一棵树呢？如果树的所有分支都是独立递归地生成的(想象一下棋类游戏中的移动树)，那么根据到目前为止生成的信息的各种条件，在不同的深度切割不同的分支是有意义的。

如果最初的作者没有为我的用例或足够通用的用例类做好准备，我就倒霉了。懒惰infiniteLoop的作者可以用自然的方式编写它，让每个单独的调用者懒洋洋地探索他们想要的东西；两者都不需要对对方了解太多。

此外，如果停止懒洋洋地探索无限输出的决定实际上与调用方对该输出所做的计算交织在一起(并依赖于该计算)怎么办？再想想国际象棋移动树；我想探索这棵树的一根树枝有多远，这很容易取决于我对我在其他树枝上找到的最佳选择的评价。所以，要么我进行两次遍历和计算(一次在终止条件下返回一个标志，告诉infinteLoop停止，然后再次使用有限的输出，这样我才能真正得到我的结果)，或者infiniteLoop的作者必须为不仅仅是终止条件做好准备，而且还要为一个复杂的函数返回输出(这样我就可以将整个计算推到“终止条件”中)。

在极端情况下，我可以探索输出并计算一些结果，将其显示给用户并获取输入，然后继续探索数据结构(而不根据用户的输入来回忆infiniteLoop )。“懒惰的infiniteLoop”的原作者根本不知道我会想到做这样的事情，而且它仍然会起作用。如果我们得到了由类型系统强制执行的纯度，那么如果终止条件需要(例如，通过给整个事物一个一元接口)，则除非允许整个infiniteLoop具有副作用，否则这是不可能的。

简而言之，为了允许同样的灵活性，通过使用一个严格的infiniteLoop来控制它可以获得同样的灵活性，它需要更高的阶函数来控制它，对于infiniteLoop的作者和它的调用者来说，这可能是一个额外的复杂性(除非公开了各种更简单的包装，其中一个与调用者的用例相匹配)。懒惰的评估可以让生产者和消费者几乎完全解耦，同时仍然让消费者能够控制生产者产生的产量。你可以用额外的函数参数做任何事情，就像你说的那样，但它要求生产者和消费者就控制功能的工作方式从本质上达成协议；而且该协议几乎总是专门针对手头的用例(将消费者和生产者绑在一起)，或者是复杂的，以便使生产者和消费者完全依赖于该协议，这在其他地方不太可能被重新创建，因此它们仍然是捆绑在一起的。