Hotdry.

Article

Effekt 语言中的 Effect Handlers 与 Recursion Schemes：代数效应的函数式控制

深入解析 Effekt 语言如何结合 effect handlers 与 recursion schemes，探讨代数效应在函数式编程中的副作用控制与模式化递归机制。

2026-04-23compilers

在函数式编程的历史长河中，副作用控制始终是核心议题。传统的纯函数式语言选择将副作用完全驱逐出计算本体，而近年来兴起的代数效应（Algebraic Effects）则提供了一条更为灵活的路径 —— 将副作用抽象为可解释的操作，由调用方决定其语义。Effekt 作为一门以词法效应处理器（Lexical Effect Handlers）为核心的研究型语言，不仅实现了代数效应的完整表达能力，更与递归模式（Recursion Schemes）形成了深刻的理论呼应。本文将从机制到实践，剖析这两大概念在 Effekt 中的融合方式。

效应签名与操作声明

Effekt 的效应系统起始于效应签名（Effect Signature）的声明。在语言层面，签名以接口（interface）的形式出现，类似于对象系统中对抽象方法的定义。例如，经典的异常效应可以这样声明：

interface Exception {
  def throw(msg: String): Nothing
}

此处的 interface 定义了一个名为 Exception 的效应签名，其中包含一个名为 throw 的操作，接收字符串消息并返回 Nothing（即永不返回）。效应签名的核心作用是声明可能发生的副作用操作，而不涉及这些操作的具体实现逻辑。

与普通对象方法调用不同，当操作被用作效应时，需要在调用前加上 do 关键字：

def div(a: Double, b: Double) =
  if (b == 0.0) { do throw("division by zero") }
  else { a / b }

这种语法上的区分至关重要：普通方法调用意味着我们知道接收者的具体实现，而效应操作则将执行的决策权交给上下文。函数的返回类型会显式标注其产生的效应 —— 上述 div 函数的类型为 Double / { Exception }，斜杠右侧即为该函数可能触发的效应集合。

效应处理器的解释器模式

效应操作的声明只是问题的上半部分，谁来实现这些操作才是关键。Effekt 通过 try...with 语法提供效应处理器（Effect Handler），使调用方能够为效应操作提供具体解释：

def unsafeDiv(a: Double, b: Double): Double / {} =
  try {
    div(a, b)
  } with Exception {
    def throw(msg) = {
      panic(msg)
    }
  }

处理器的工作机制可以类比解释器模式：效应操作对应抽象语法树中的节点，而处理器则提供对该节点的解释。不同的处理器可以赋予同一效应操作完全不同的语义，这种解耦正是代数效应的精髓所在。

值得注意的是，Effekt 区分了非恢复式（Non-resumptive）与恢复式（Resumptive）效应。非恢复式效应如 throw，在处理后不会恢复执行 —— 控制流被直接中止，剩余计算被丢弃。而恢复式效应则允许通过 resume 机制继续执行中断的计算。

恢复式效应与生成器模式

恢复式效应的典型应用是生成器（Generator）。以斐波那契数列为例，我们可以定义一个 Yield 效应来实现无限序列的生成：

interface Yield[A] {
  def yield(x: A): Unit
}

def fib(): Unit / { Yield[Int] } = {
  def inner(a: Int, b: Int): Unit = {
    do yield(a)
    inner(b, a + b)
  }
  inner(0, 1)
}

在 fib() 的执行过程中，每次调用 do yield(a) 都会将控制权转移给最近的处理器，同时捕获后续计算作为隐式的 resume 参数。处理器可以决定是否恢复、以及以何种方式恢复：

def genFibs(limit: Int): List[Int] / {} = {
  var count = 0
  var fibs = []
  try {
    fib()
  } with Yield[Int] {
    def yield(x) =
      if (count < limit) {
        count = count + 1
        fibs = Cons(x, fibs)
        resume(())
      }
  }
  fibs
}

此处处理器在收集指定数量的斐波那契数后，通过调用 resume(()) 继续执行生成器。这种模式天然对应协程（Coroutine）的行为，而在 Effekt 中，它仅仅是效应处理器的一个应用场景。

Effekt 还支持链式处理器的组合使用。通过 with 关键字，可以将多个处理器扁平化地串联：

def evenFibs(limit: Int): List[Int] = {
  with collect(limit)
  with filter { x => x.mod(2) == 0 }
  fib()
}

这种设计使得处理器可以被模块化地组合，每个处理器负责单一的变换逻辑，类似于管道（Pipeline）模式。

递归模式与效应控制的理论呼应

递归模式（Recursion Schemes）源于范畴论，其核心思想是将递归的结构与对该结构的操作分离。最基本的两种模式是catamorphism（余代数态射折叠）与anamorphism（代数态射展开）：前者将递归数据结构 “折叠” 为单一值，后者从一个种子 “展开” 为递归结构。

这两类模式与 Effekt 的效应系统在抽象层面高度相似：

递归模式 效应处理器 核心抽象
分离数据结构的形状与遍历方式 分离效应操作的声明与解释 关注点分离
catamorphism 通过指定每层如何组合来消费结构 处理器通过指定每种操作如何响应来解释效应 模式化的解释
anamorphism 通过指定每层如何生成来构建结构 效应操作描述 “想要做什么”，处理器决定 “如何做” 双向解耦

从技术角度看，递归模式是数据层面的模式化递归，而代数效应是控制层面的模式化解释。两者都遵循 “描述做什么，而非如何做” 的原则。在实际工程中，这种共性意味着：当我们在 Effekt 中编写递归函数时，可以同时受益于效应系统提供的副作用控制能力 —— 递归的 “形状” 由函数定义，副作用的 “语义” 由处理器提供。

工程实践中的参数化考量

在生产环境中使用 Effekt 风格的效应系统时，以下参数值得注意：

效应类型推断：Effekt 支持轻量级效应系统，函数的返回类型会自动推断其产生的效应集合。开发团队应确保关键入口函数的效应签名清晰，便于静态分析与组合。

处理器嵌套深度：虽然 with 语法支持扁平化组合，但过深的处理器链仍可能影响可读性。建议将复杂的数据流管道拆分为独立的辅助函数，每个函数负责单一的处理阶段。

恢复式效应的恢复次数：对于需要多次恢复的效应（如非确定性回溯），处理器需要显式管理每次恢复的生命周期。监控恢复次数与内存占用的关系，是性能调优的关键指标。

效应与类型系统的边界：Effekt 的效应签名是类型的一部分，这意味着效应系统本身是静态安全的。但在与外部系统交互时，需要考虑效应签名的序列化与跨边界传递问题。

小结

Effekt 语言通过词法效应处理器，为代数效应提供了一种兼具表现力与安全性的实现方案。效应签名声明操作、处理器解释操作的二层架构，与递归模式在理论层面形成了优雅的呼应 —— 两者都强调描述与解释的分离。在实际工程中，这种设计使得副作用控制可以像乐高积木一样被模块化组合：业务逻辑描述 “做什么”，而基础设施决定 “如何做”。对于追求高度可组合性、强类型安全性与纯净业务逻辑的函数式编程实践，Effekt 的效应系统提供了一个值得深入探索的现代范式。

参考资料

compilers