Haskell conduit库中.|运算符为何设为右结合（infixr）？

Conduit库中用于连接管道组件的.|运算符是**右结合（infixr）**的，并且它对右参数始终严格求值。这意味着运行管道时，必须从第一个组件开始递归遍历到最后一个组件，等最后一个组件生成结果或确定无需输入后，再逐层回溯退出——哪怕最后一个组件是return ()这种无需输入就立即返回的情况也是如此。

如果.|是左结合的，遇到类似最后一个组件立即短路的场景，管道可以直接退出，不需要多余的递归步骤。这就带来一个疑问：为什么要将.|设计为右结合？从性能角度看它似乎存在明显劣势，是不是有未被注意到的优势？

示例对比 #

假设有如下管道代码：

yieldMany [0..10] .| mapC (*2) .| mapC (+4) .| return ()

右结合的解析与求值

右结合规则下，代码会被解析为：

yieldMany [0..10] .| (mapC (*2) .| (mapC (+4) .| return ()))

由于.|对右参数严格求值，执行时会先计算最外层左侧的.|，接着递归计算中间的.|，直到执行到最内层的return ()。确认该组件无需输入后，才会逐层回溯退出整个管道，产生了不必要的递归开销。

左结合的解析与求值

如果是左结合，代码会被解析为：

((yieldMany [0..10] .| mapC (*2)) .| mapC (+4)) .| return ()

此时最顶层的是最右侧的.|，会先计算return ()，发现它无需上游输入，直接短路退出整个管道，不需要递归遍历前面的组件。

右结合设计的优势 #

尽管右结合在某些短路场景下存在性能损耗，但它的设计是基于Conduit的核心目标和使用场景：

• 贴合数据流直觉：Conduit的数据流是从左到右传递，右结合的嵌套结构更符合“上游组件将数据传递给下游嵌套组件”的逻辑，代码结构和数据流动方向一致，可读性更强。
• 类型推导更顺畅：Conduit的组件类型（Source、Conduit、Sink）组合依赖于右结合的嵌套方式，左结合会让类型推导变得复杂，尤其是在混合不同类型组件时，右结合能自然满足类型约束。
• 资源管理更可靠：Conduit主打安全的资源自动管理，右结合的嵌套结构能保证资源的初始化和释放严格遵循“下游先初始化、上游先释放”的回溯顺序，确保每个组件的资源都能正确清理，避免泄漏。
• 组件组合更灵活：右结合支持先组合好下游的组件链，再和上游组件结合的模式，这种部分应用的方式在构建复杂管道时更便于组件复用和逻辑拆分。

内容的提问来源于stack exchange，提问作者Kwobny