从效应思考一切
从效应思考一切
一、参数是消息还是绑定
对于一般的函数调用，有两种基本的思考方向。一种是将参数视为传递给函数的消息，函数作为一个接收消息并做出响应的实体。这类似于面向对象中的消息传递风格，或者像HTTP请求中参数作为请求体。这种思路强调函数与调用者之间的通信或交互，适合命令式、面向对象或事件驱动的编程模型，其中函数通常有副作用，参数携带指令或数据。它的优点在于符合日常语言中"把信息告诉某人"的直觉，易于理解。但缺点是可能会让人忽略参数对函数内部执行环境的影响，容易陷入"函数只是黑箱"的思维，不利于深入理解闭包、作用域链等机制。
另一种思路是将参数视为临时或延迟绑定到函数执行环境的值。函数本质上是一个表达式，函数调用就是将参数绑定到形参上，从而建立一个新的执行环境，然后在该环境中求值函数体。这源于λ演算中的β归约。这种思路精确反映了静态作用域、闭包和环境模型的实际工作方式，在函数式编程中天然支持高阶函数、柯里化和部分应用，能清晰理解延迟绑定和惰性求值。但它对初学者可能更抽象，需要理解环境、绑定、符号替换等概念，在强调副作用的场景中显得不够直接。
从某种角度看，环境绑定的思路更接近现代语言的实现底层，有助于深入理解作用域链、闭包和参数传递的本质，但消息传递的思路更适合快速入门。从设计范式看，在消息传递风格中前者更自然，在纯函数风格或λ演算中后者是基石。从实用性看，大多数情况下两者是等价的，可以把绑定看作消息的具体实现机制。但如果需要讨论延迟求值、回调或Promise，环境绑定的思路优势明显，因为它自然支持参数还未被求值、只是绑定了将来会求值的表达式。如果必须二选一，环境绑定更具基础性，因为λ演算是计算模型的核心，且能统一解释函数调用、闭包和延迟绑定的所有细节。
二、将参数视为局部显式环境
沿着环境绑定的思路，参数只是函数执行环境中最显眼的一部分。函数被调用时，一个新的局部环境被创建，参数被绑定到这个环境中的变量名上。在这个局部环境内，还可以声明局部变量，这些变量只在函数执行期间存在，函数返回后随之销毁。局部变量和参数共同构成了函数的显式执行环境——显式是因为它们都通过语法明确声明，局部是因为它们的生命周期严格限定在一次调用之内。
这个局部显式环境是编程中最容易理解的概念。每个函数调用都有自己的一份参数和局部变量，互不干扰。递归调用时，每一层调用都在栈上创建独立的环境帧，同一函数的多次调用可以同时存在于调用栈上而彼此隔离。这种隔离性使得局部环境成为安全的计算空间：在这里面进行的操作，只要不触及外部状态，就不会产生副作用。
但局部环境并非自足的。函数往往需要访问超出自身声明范围的数据：全局变量、环境变量、文件内容、网络响应、用户输入。这些数据不是通过参数显式传入的，而是函数在执行过程中从外部获取的。于是，局部显式环境之上，还有一个更广阔的环境层。
三、全局隐式环境
环境变量的读取、全局状态的访问、闭包对外部变量的捕获——这些都可以看作是从一个更大的环境中获取绑定值。环境变量在程序启动时绑定一次，全局变量在模块加载时初始化，闭包捕获的变量在闭包创建时确定。它们与参数的区别在于绑定时机和作用范围：参数在每次调用时绑定，局部变量在函数体内声明，而环境变量和全局状态在程序运行前或运行初期就已确定，对函数而言是只读的隐含输入。
这个更大的环境可以用Reader单子来建模：函数隐含地依赖一个环境值，这个值不通过参数传递，但影响函数的输出。在类型系统中，这种依赖可以被显式标注，从而将隐含输入转化为显式契约。当函数读取环境变量时，它实际上是在执行一个从环境中提取绑定值的操作，这个操作本身是一种效应——因为它依赖于外部状态，且这个状态不在函数的局部控制之内。
环境的概念还可以进一步扩展。用户输入、文件读取、网络请求，这些操作同样是从外部环境中获取值，但它们与静态环境变量的区别在于：获取的值在运行时才确定，且每次获取可能得到不同的结果。它们是延迟条件绑定值，绑定时机不确定，绑定结果不可预测。这使得它们超出了普通环境绑定的范畴，进入了IO单子的领域。
四、环境操作是一种效应
如果将环境交互视为隐含绑定，那么所有对外部状态的读取和写入都可以统一为效应。读取环境变量是一种效应，因为它依赖于程序外部的一个状态。用户输入是一种效应，因为它在运行时与外部世界交互。文件和网络操作是效应，因为它们改变了或依赖于持久化存储和远程状态。甚至内存分配也可以视为效应，因为它修改了堆的状态。
更进一步，如果将保存到内存也视为效应，那么传统意义上"纯计算"与"副作用"的界限就被消除了。一个加法运算中，操作数是从环境或内存中读取的绑定值，这隐含了读内存的效应；计算结果需要保存到某个位置才能被后续使用，这隐含了写内存的效应。从这个角度看，程序不是"计算加副作用"，而是效应的序列编排。算术运算是纯效应——它不依赖外部世界，只依赖之前绑定好的值，但它仍然是效应，因为它消耗了计算资源并产生了新的绑定值。
这种视角下，所有输出都是效应。返回值不是简单的数据传递，而是将计算结果写回调用者的环境。控制台输出是写效应，文件写入是写效应，内存赋值也是写效应。程序的运行过程就是一条效应历史轨迹：从初始世界状态出发，依次执行读内存、计算、写内存、读输入、写输出等效应，最终到达一个终态世界。
这种思想呈现出生成式的特征。程序不是描述"是什么"的静态表达式，而是生成一系列效应的动态过程。函数调用不是在当前效应轨迹上追加一段新轨迹。这与传统的函数式演绎式思路形成对比：演绎式描述的是映射关系，给定输入输出确定；生成式描述的是过程结构，如何从初始状态演化到最终状态，有时间感和历史轨迹。
两种范式互为对偶。用生成式的语言写程序，用演绎式的语义理解程序；或者反过来，用演绎式写纯核，用生成式编排副作用。Haskell的Monad是这两者的桥梁：类型层面是纯的、演绎式的，语法层面通过do记号呈现出生成式的序列感。本质是用纯的演绎系统编码了一个生成式的效果编排语言。
五、最小效应
如果一切都是效应，那么函数式编程的定义就不能建立在"无效应"之上，而必须建立在"最小效应"之上。最小必要效应仅用于完成纯计算所必需：读参数效应、计算效应、返回效应、终止效应。这四项构成最小效应集。任何超出这个集合的效应——堆内存分配、IO、异常、随机数、系统调用、写全局状态、捕获闭包环境——都会使函数超出函数式的范畴。
在这个框架下，栈效应属于最小效应集，因为函数调用自动管理栈帧，参数传递、局部变量分配和函数返回都通过栈完成。堆效应不属于最小效应集，因为堆分配需要显式的内存管理，且分配的对象生命周期超出单次函数调用。这就是为什么严格意义上的函数式程序只能使用栈而不能使用堆。
高阶函数本身不违反最小效应原则，但返回闭包就违反了，因为闭包需要捕获外部变量并存储在堆上。按这个标准，许多语言中被视为函数式特性的写法实际上都引入了超出最小效应集的效应。递归如果仅使用栈则属于最小效应集，但深度递归可能导致栈溢出，这通常被视为实现限制而非语义层面的效应。
最小效应集的能力边界是：只能使用进入函数时已在栈上的值，执行纯计算，返回单个值。所有数据必须在编译时已知大小，不能有动态数组、字符串、对象。这个子集在C语言中对应于不用malloc、setjmp、文件IO、全局变量、静态变量、volatile的代码，且依然图灵完备，因为无界递归加栈足够模拟任意计算。
六、函数式的最小定义
综合以上思路，函数式可以定义为：程序的一个子集，其中所有函数只使用最小效应集——参数读取、栈上的局部变量分配和访问、算术逻辑比较计算、条件跳转、函数调用、返回值传递、函数终止——并且不使用其他任何效应。简单记忆就是只用寄存器、栈、程序计数器和ALU写的程序，不碰堆、文件、网络、时间、随机、异常、可变全局状态。
这个定义不依赖于不可变性、递归、高阶函数等表面特征，只依赖于一个概念：效应。它划清了边界：读取环境变量的函数不是函数式，写控制台的函数不是函数式，抛出异常的函数不是函数式，不终止的函数不是函数式。只有参数和返回值之间、在最小效应集内完成的计算才是函数式。
这个定义是激进的，因为它排除了现有绝大多数自称函数式的代码，包括Haskell的绝大多数程序。但它也是一致的：如果一切都是效应，那么函数式就是效应的最小子集，是在效应光谱上最靠近纯计算那一端的点。这个点虽然小，却构成了所有复杂程序的基石——因为任何程序，无论多么复杂，其内部都包含着大量符合最小效应集的子计算。理解这些子计算的本质，就是理解函数式编程的意义。
七、单一效应原则
基于上述分析，可以提出一个实用的编码原则：除了集成式和分派式的函数，其他函数应尽量保持单一效应。
集成式函数的职责是将多个独立的效应组合成一个完整的业务流程。例如一个处理用户请求的HTTP处理器，它需要读取请求体、查询数据库、调用外部API、写入日志、返回响应。这种函数天然是多效应的，因为它的存在意义就是协调各种异构的效应。分派式函数的职责是根据输入决定调用哪个子函数，例如路由分发器、策略选择器、工厂方法。这类函数的核心逻辑是条件判断和函数指针跳转，本身不执行具体的效应操作，但会引导控制流进入不同的效应分支。
除了这两类函数，普通的业务函数、工具函数、计算函数都应该遵循单一效应原则。一个函数如果同时做计算和打印日志，就混合了最小效应和写控制台效应。一个函数如果既查询数据库又发送网络请求，就混合了两种不同的外部效应。这种混合带来的问题不是功能上的错误，而是理解上的困难：当需要追踪某个效应的来源时，混合效应的函数会制造不必要的认知负担。
单一效应原则的具体实践是：纯计算函数只使用最小效应集，不接触任何外部状态。这类函数接收参数，在栈上进行计算，返回结果。它们是程序中最稳定、最可测试、最容易推理的部分。外部效应函数则应该只执行一种类型的效应：只读文件的函数不碰网络，只写数据库的函数不做计算，只打印日志的函数不读配置。每个函数在效应光谱上占据一个明确的位置，而不是横跨多个区域。
这种划分的好处在于，程序的效应结构变得透明。打开一个函数，扫一眼就能判断它属于哪一类效应：纯计算、文件IO、网络IO、数据库操作、日志输出。当需要修改某个效应的行为时，知道去哪里找；当需要添加新的效应时，知道在哪里插入。集成式函数作为效应编排的顶层，清晰地展示了整个程序的效应流程图。分派式函数作为控制流的枢纽，将请求路由到正确的效应处理器上。而底层的单一效应函数则是可复用的积木，可以在不同的编排场景中被组合使用。
单一效应原则与最小效应定义是互补的。最小效应定义回答了什么是最纯粹的计算，单一效应原则回答了如何在实践中组织不纯粹的计算。两者共同构成了一套从理论到实践的完整框架：识别最小效应集，将纯计算隔离出来，将剩余的外部效应按类型分离，最后用集成式函数将它们编排成完整的程序。