在程序设计中，人们不断尝试以更加精确、更加结构化的方式描述“计算在做什么”。纯函数、引用透明性、类型系统，这些概念之所以被反复讨论，并非源于形式美感，而是因为它们提供了一种高度可推理的计算描述方式。然而，一旦程序需要处理异常、状态、输入输出、并发、非确定性等行为，这种清晰性便会受到挑战。如何在不摒弃函数式核心思想的前提下，对这些行为进行严谨描述，成为研究的重要议题。Algebraic Effects 正是在这样的背景下受到广泛关注的一种理论与实践框架，它尝试以代数与操作语义的方式，对“效果”进行抽象、组合与解释，从而在程序结构层面给出一种更统一的表达。
1 从计算语义到程序结构
在现代程序设计语言研究中，开发者和语言理论学者一直关注如何精确、结构化地描述计算行为。在早期的函数式编程中，纯函数与引用透明性提供了一种理想化的计算模型：每个函数的输出完全由输入决定，没有任何隐含的状态或者外部副作用。这种模型具有强大的可推理性和数学严谨性，因此可以直接借助λ演算和类型系统进行分析和证明。函数式语言中常见的类型系统，如ML家族或Haskell的类型系统，不仅保证了程序的类型安全，也在一定程度上约束了程序的行为，使得程序的逻辑结构和数学模型高度一致。
然而，随着实际软件系统的复杂化，程序往往不仅需要执行纯计算，还需要处理异常、可变状态、输入输出、并发操作、非确定性计算、资源管理等行为。这些行为超出了纯函数计算的范畴，使得简单的输入输出映射不再能够准确描述函数的行为。举例来说，考虑一个函数，如果在计算过程中还需要记录日志或者更新某个全局计数器，那么的行为已经不再仅仅由输入整数决定，而是受到计算环境的影响。这就引入了“效果”（effects）的概念，它反映了计算对外部环境的操作或者计算本身附带的额外信息。
处理这些效果的传统方式在函数式编程中通常依赖单子（Monad）。单子通过类型系统将效果嵌入到类型结构中，使得效果的传播显式化。例如，Haskell中IO类型就是一种封装输入输出操作的单子类型，程序员必须在类型系统的约束下处理这些操作。然而，单子虽然能够在理论上统一各种效果，但在实践中会出现几个问题：
组合复杂度高：当程序中有多种效果，如状态、异常、并发等，单子通常需要通过单子变换器（monad transformer）进行组合。这会导致类型签名变得冗长且难以维护，例如一个函数的类型可能是 StateT s (ExceptT e IO) a，这种嵌套不仅增加理解难度，也限制了模块化编程的灵活性。
效果顺序固定：单子模型要求效果的顺序在类型层面固定，这意味着改变效果组合顺序通常需要对程序做较大修改，缺乏灵活性。例如，如果希望先处理异常再处理状态，或者反之，可能需要重新定义单子栈结构。
定义与解释耦合：在单子模型中，效果的定义者往往同时承担了效果的解释逻辑，这导致程序的可组合性受到限制。不同模块如果希望以不同方式解释同一种效果，需要额外的适配层或者重复代码。
这些问题促使研究者寻找一种能够在保持函数式核心特性的前提下，更灵活地描述和组合效果的理论框架。Algebraic Effects 就是在这种需求背景下发展起来的。它提供了一种以代数操作和操作语义为基础的抽象机制，允许程序在不依赖特定执行顺序或具体实现的情况下，声明计算可能涉及的效果。同时，Algebraic Effects 引入了“handler”机制，使得程序中效果的解释可以延迟到处理阶段，这样程序的计算逻辑与效果的实现逻辑被明确分离，从而增强模块化和可组合性。
在这一框架下，程序的核心计算可以被视为由纯函数构成的主干，而效果则以操作符的形式附加在计算结构上。这些操作符本身是抽象的，不指定具体行为，而是由处理器决定如何执行。例如，对于异常效果，可以定义一个抽象操作 raise : E -> a，程序中只需要调用 raise 并提供异常值，而异常的捕获和处理则由 handler 实现。这种方法不仅统一了对异常、状态、输入输出等不同效果的表达，也使得程序逻辑更清晰：程序员可以专注于计算的业务逻辑，而不被具体效果的执行细节所干扰。
从数学语义角度来看，Algebraic Effects 可以被理解为自由代数（free algebra）的操作。设为效果操作的集合，每一个计算都可以看作是自由代数中的元素，其中是纯值类型的集合。计算本身并不执行效果，而是生成一个结构化的表达式树，每个节点表示一个操作或纯值。形式化表示为：
其中，，是后续计算的继续（continuation）。这种形式化结构使得程序不仅可执行，还可进行推理、优化和变换，而不破坏程序的行为逻辑。
Handler 机制则可以形式化为一个代数同态映射，将自由代数结构映射到具体语义域中。例如，对于状态效果，处理器可以将每个get和put操作映射为对环境中状态的读写操作，而对于异常效果，处理器可以将raise操作映射为异常传播逻辑。不同的处理器对同一计算结构可以产生不同的行为结果，从而实现效果的多态解释和灵活组合。
通过这种方式，Algebraic Effects 不仅提供了一种统一的效果建模手段，也为程序语义的分析和程序结构优化提供了坚实基础。它允许研究者和程序设计者在不降低函数式特性和可推理性的前提下，将复杂的外部行为纳入到可调控制、可组合的计算框架中。
总而言之，函数式编程中的 Algebraic Effects 代表了一种新的计算抽象方式：它通过代数操作和处理器分离，将程序的核心逻辑与外部效果实现解耦，使得效果可以被组合、重解释和形式化分析。这不仅提升了程序设计的灵活性，也为大型函数式系统提供了更清晰、更可推理的结构。Algebraic Effects 的出现标志着函数式编程在处理现实复杂计算行为时，获得了一种理论上严谨且实践上可操作的新途径。
2 从“效果”问题谈起
在深入理解 Algebraic Effects 之前，有必要对“效果”在计算语义中的含义进行系统阐述，并分析传统方法在处理这些效果时面临的局限性。效果不仅仅是程序执行时的副作用，它更是程序结构与语义分析中不可忽视的重要维度。通过对效果的明确定义与分类，可以为 Algebraic Effects 提供理论基础，同时也能理解为什么传统方法在组合性和模块化上有困难。
2.1 什么是计算中的效果
在函数式编程下，计算通常被理想化为一个从输入到输出的数学映射：如果函数 对应输入 输出 ，我们记作
其中 是输入类型集合， 是输出类型集合。在纯函数的模型下，对于相同的输入 ， 总是得到相同的输出，不会依赖外部状态或产生任何可观察副作用。这种特性被称为引用透明性（referential transparency），它是函数式编程的核心。
然而，实际程序往往需要处理的不仅仅是纯计算。例如：
- 状态修改：函数在执行过程中修改某个状态变量，例如计数器或缓存。
- 异常处理：函数可能在特定条件下抛出异常，改变控制流。
- 输入输出：函数可能读取文件、网络数据，或输出日志和用户界面信息。
- 非确定性或并发操作：函数可能返回不同的结果，或者涉及线程交互和资源竞争。
这些行为都超出了数学函数的纯映射范畴，因此称为效果（effect）。从形式语义角度，效果可以视为一种对计算过程的扩展，使得计算不仅返回值 ，还可能返回或影响某种上下文信息。一个常用的数学建模方式是将计算视为带有效果的函数：
其中 表示效果上下文（effect context），它不仅包含返回值，还包含与计算相关的状态、异常或外部交互信息。例如，对于状态效果，可以定义
其中 是状态空间，函数既返回新的状态 ，也返回结果 。同样，对于可能抛出异常的函数，可以定义
其中 是异常类型， 表示返回结果 或者异常 。这种形式化视角显示，效果可以系统化地建模为函数签名的扩展，但仍保持可推理性。
在命令式语言中，这类效果往往隐式出现，例如 C、Java 中的赋值、异常和 I/O 操作都直接修改环境或状态。然而在函数式语言中，为了保持计算的可推理性，效果必须被显式建模。也就是说，每个操作涉及的效果都需要在类型或结构中明确体现，从而保证程序逻辑与效果实现的可分离性。
效果的显式建模不仅有助于理论分析，还对程序结构化设计、模块化开发和形式化验证提供了基础。例如，当程序依赖外部状态时，如果没有显式效果描述，程序的行为可能因外部环境变化而不可预测；而通过显式建模，程序员可以清楚地知道哪些函数可能读取或修改状态，哪些函数是纯函数，从而实现更可靠的模块组合。
2.2 传统解决方案的局限
函数式编程中最广泛使用的效果建模方式是单子（Monad）。单子是一种类型构造器，它将效果封装到类型中，并提供绑定操作 或者 >>=，以保证效果按特定顺序传播。典型例子包括：
- IO单子：封装输入输出操作，使其在纯函数上下文中可组合。
单子的基本形式可以表示为：
其中 将纯值提升为单子， 实现顺序化的计算链，将效果从一个计算传递到下一个计算。
单子在理论上提供了一个统一机制来处理各种效果，并保持函数式编程的核心特性。然而，当程序中涉及多种效果组合时，单子模型表现出显著局限：
当程序需要同时处理状态、异常和 I/O 时，单子通常需要嵌套或使用单子变换器（monad transformers）。例如，将状态与异常组合，可能得到类型：
这种嵌套带来两个问题：类型签名冗长且难以理解，程序逻辑容易被类型结构绑住，增加了代码维护成本。此外，不同效果的组合顺序会影响类型签名和执行顺序，使得程序的灵活性下降。
单子模型将计算顺序与类型结构绑定，意味着程序在设计阶段必须决定效果的执行顺序。例如，先处理异常再处理状态，或者反之，都会影响最后类型签名和计算行为。如果需要改变顺序，程序需要重写单子栈或增加适配器，这对大型系统而言非常繁琐。
在单子模型中，效果的定义者往往同时承担效果解释的责任。也就是说，计算的调用逻辑与效果的执行逻辑耦合在一起。这样一来，复用性和模块化受限：同一段计算在不同环境下的效果解释难以灵活切换，需要修改原有代码或增加重复逻辑。
综上，单子虽然在理论上可以处理各种效果，但在实践中面对多效果组合和复杂系统时，其组合性和灵活性不足。这促使研究者探索一种新的抽象机制，即 Algebraic Effects。它通过将效果操作声明与解释分离，提供了更灵活、更模块化的建模方式，使程序结构与效果实现解耦，同时保留可推理性和组合性。
3 Algebraic Effects 的基本思想
3.1 “操作”与“解释”的分离
Algebraic Effects 的核心思想之一，是将“效果的声明”与“效果的处理”分离。具体而言：
- 处理器（handler）负责为这些操作给出具体语义
这种分离带来的直接结果，是程序的计算逻辑与其效果实现之间形成清晰边界。
3.2 代数结构的引入
之所以称为“algebraic”，并非偶然。这里的效果操作通常被视为代数签名中的操作符，而程序的计算过程则可被理解为这些操作在某种自由结构中的组合。简言之：
这一视角使得效果的组合、重写与推理具备明确的数学基础。
4 形式化视角下的 Algebraic Effects
4.1 计算作为自由代数
在形式语义中，一个不含具体解释的效果计算，常被描述为某个自由代数中的元素。设有一组操作符 ，那么围绕 构造的自由结构，描述了所有可能的效果调用序列。
这意味着，程序本身并不“执行”效果，而是生成一棵描述计算结构的语法树。这棵树包含：
4.2 Handler 作为代数同态
效果处理器可以被理解为一种代数同态，它将抽象的自由结构映射到某个具体语义域中。不同的 handler，对同一计算结构可以给出完全不同的解释。
同一段程序，在不同处理规则下，会呈现怎样的行为差异？这种差异是否可以被系统性分析？
5 与异常、状态等经典机制的关系
5.1 异常作为效果
异常机制可以被描述为一种效果操作。例如：
在这种框架下，异常不再是一种语言内建的控制流中断方式，而是一个普通的效果操作，其传播与捕获逻辑由处理器定义。
5.2 状态操作的抽象
可变状态通常涉及读取与写入两个操作。通过 Algebraic Effects，可以将状态抽象为：
程序只描述何时读取、何时更新，而状态的具体存储方式由 handler 决定。这种方式允许在不修改程序主体的情况下，切换不同状态策略，例如线程局部状态或全局状态。
6 与单子模型的比较
6.1 表达能力的对照
从理论上看，许多代数效果都可以通过单子进行编码；反之亦然。然而，两者在表达方式上有显著差异：
- Algebraic Effects 强调“操作的声明与解释”
在复杂系统中，后者往往更有利于模块化设计。
6.2 组合性的差异
当多种效果同时出现时，单子方案通常要求提前决定组合顺序；而代数效果允许在处理阶段再决定不同操作如何相互作用。这种延迟决策能力，使程序结构更加灵活。
7 推理、重构与程序理解
7.1 等价变换的可能性
由于效果操作具有明确的代数语义，程序在一定条件下可以进行结构化变换，而不改变其外在行为。这为程序重构提供了坚实基础。
7.2 程序理解层面的收益
当效果被显式声明并集中处理时，程序的阅读者可以更清楚地判断哪些部分涉及外部行为，哪些部分保持纯粹计算。这种区分对于大型系统尤为重要。
8 结语
Algebraic Effects 提供了一条不同于传统路径的思路：不是通过不断增加语言内建机制来覆盖各种行为，而是通过抽象操作与解释规则，形成一个可扩展、可组合的效果描述体系。它所强调的并非某种特定技巧，而是一种结构化理解计算行为的方式。这种方式正在逐步影响函数式语言设计，也为程序语义研究提供了持续的思想资源。
