为什么某些 Prelude 函数是根据本地定义的函数来定义的？ [复制]

Question

我正在查看一些前奏函数来教同事递归，我发现有些是以一种相当奇怪的方式编写的。示例：

{-# NOINLINE [1] zipWith #-}
zipWith :: (a -> b -> c) -> [a] -> [b] -> [c]
zipWith f = go
  where
    go [] _ = []
    go _ [] = []
    go (x:xs) (y:ys) = f x y : go xs ys

为什么它被写成对go 的调用，而go 是在之后定义的？ IMO 更自然的定义方式是：

zipWith :: (a -> b -> c) -> [a] -> [b] -> [c]
zipWith _ [] _ = []
zipWith _ _ [] = [] 
zipWith f (x:xs) (y:ys) = f x y : zipWith f xs ys

我猜这是由于一些 inline / loop-fusion / lazy / whatever-feature 允许 GHC 更好地优化，但这就是 Haskell 对我来说变得非常模糊的地方.任何人都可以解释（尽可能简单）这种函数定义的原因，如果有的话。

编辑

许多 cmets，@AndrewRay 的回答以及在这个 question 中，都指出内联的方向是这种辅助局部函数的原因。尽管如此，zipWith 被标记为 pragma NOINLINE [1] zipWith，直到 GHC's user guide: 7.13.5.5. Phase control，意味着在第一阶段之前不内联，并且可能在之后内联（无论这意味着什么）。在链接的问题中，PO 指的是foldr，它是使用相同的技巧实现的，但没有任何 PRAGMA。我认为作者正在避免内联，但我对此的了解很少。

编辑 2

添加了source定义zipWith的链接

Answer 1

正如 Willem Van Onsem 在他的评论中提到的，这意味着 f 不需要在每个递归调用中传递。

您的函数版本使用递归调用zipWith f xs ys。因为f 是zipWith 的参数，所以它必须重复传递。这意味着从zipWith 来看，f 永远不会从一个递归级别更改为下一个级别，这一点并不明显。

Prelude 版本使用递归调用go xs ys，它立即表示对go 的每个递归调用都使用相同的f。能够立即注意到这样的不变量有助于我们对代码进行逻辑推理。

编辑：我之前认为内联在这里无关紧要，但是 Carl 和 Daniel Wagner 都指出 thunk f 只需要评估一次并替换为go，而不是像您对 zipWith 的定义那样为每次递归重新评估。

您还提到了循环融合，即将相邻的遍历函数合并为单个遍历的过程。由于这已经是一次遍历，因此这里也不适用。