Monad 巡礼:State、Reader、Writer

State:纯语言里的「可变」状态

纯函数不能改状态,但可以传递状态:吃旧状态,吐新状态,让「变化」变成一串各自不可变的快照。问题是手动传实在难看——给树的每个节点按遍历顺序编号,状态是「下一个编号」:

label :: Tree a -> Int -> (Tree (Int, a), Int)      -- 吃编号,吐(结果, 新编号)
label Leaf         n = (Leaf, n)
label (Node l x r) n =
  let (l', n1) = label l n          -- 左子树用掉一些编号
      (x', n2) = ((n1, x), n1 + 1)  -- 当前节点用一个
      (r', n3) = label r n2         -- 右子树接着用
  in  (Node l' x' r', n3)

能跑,但 n、n1、n2、n3 这条「状态穿线」全是样板:每一步都在重复「把上一步吐出的状态喂给下一步」,而且穿错线(比如把 n1 喂给了右子树)编译器拦不住——纯是纯了,危险还在。重复的模式 → 抽出来(第 5 章教的)。把「带状态的计算」定义成一种值,把穿线塞进 >>=:

newtype State s a = State (s -> (a, s))   -- 「吃状态吐(结果,新状态)」的函数,装进盒子

-- 它的 >>= 只干一件事:替你穿线
-- (State f) >>= g = State $ \s -> let (a, s') = f s in runState (g a) s'

get    :: State s s          -- 拿当前状态
put    :: s -> State s ()    -- 换新状态
modify :: (s -> s) -> State s ()

label :: Tree a -> State Int (Tree (Int, a))
label Leaf         = pure Leaf
label (Node l x r) = do
  l' <- label l
  n  <- get
  put (n + 1)
  r' <- label r
  pure (Node l' (n, x) r')

-- runState (label tree) 0 才真正开跑——State 和 IO 一样,先配方后执行

n1/n2/n3 全部蒸发:分号之间,状态自动流动。注意两个要点。其一,没有任何东西被修改——底下还是那个「旧状态进新状态出」的纯函数,State 只是把管道焊好了,所以它完全可测、可回放。其二,runState 给初始状态才执行,「描述与执行分离」再次出现——这是 IO 教过你的模式,此后每个 Monad 都是这个套路。

Reader:人人要读,没人要改

第二种样板:配置。数据库连接、功能开关、当前用户——几乎每个函数都要,却几乎没人改。手动传参的版本,每个函数签名都拖着 Config -> 的尾巴,而且中间层最冤:自己不用 Config,只因为三层之下的某个函数要,被迫全程经手,新增一个依赖就要改一整条调用链的签名。Reader 把这个「向下传递」自动化:

newtype Reader r a = Reader (r -> a)     -- 「给我环境,我给你结果」

ask :: Reader r r                         -- 任何深度,随取随用

handler :: Reader Config Response
handler = do
  req  <- validate            -- validate 内部也能 ask,但 handler 不用替它传
  conf <- ask
  pure (respond (dbUrl conf) req)

-- runReader handler prodConfig   ← 环境在最外层注入一次

眼熟吗?这就是依赖注入。Dagger/Hilt/Koin 的 @Inject、Spring 的容器、React 的 Context——都在解决同一个问题:「让深处的代码拿到外层的依赖,而不经中间层手手相传」。Reader 是这个思想的最小实现:没有注解处理器、没有反射、没有容器,一个 newtype 加一个 ask。看懂它,你对 DI 框架的理解会落地一层:依赖注入的本质是把「环境 → 结果」的函数组合起来,容器只是这件事的工业化包装。CoroutineContext 沿协程链隐式传播的设计,同样是 Reader 的亲戚。

值得停下感受一次「实现有多小」。Reader 的 Monad 实例,完整版:

instance Monad (Reader r) where
  return a = Reader (\_ -> a)                       -- 无视环境,直接给值
  (Reader f) >>= g = Reader $ \r ->
      let a = f r in runReader (g a) r              -- 同一个 r,发给每一步

四行。State 六行,Writer 五行。三个「框架级」的能力,合计十五行库代码——因为语言能直接表达「计算的形状」,模式就不必膨胀成框架。这是上游给你的第三次同款震撼(前两次:Maybe 两行、retry 四行)。

Writer:顺手记一笔

第三种样板:计算主线之外,顺手累积点什么——日志、审计轨迹、消耗的步数。Writer 的分号会把每步「附带产出」自动拼起来(用第 6 章的 Monoid,拼法由类型决定):

shipping :: Order -> Writer [String] Fee
shipping o = do
  tell ["基础运费 8 元"]
  fee <- if weight o > 10
           then do tell ["超重附加 5 元"]; pure 13
           else pure 8
  tell ["合计 " ++ show fee]
  pure fee

-- runWriter (shipping order) ⇒ (13, ["基础运费 8 元","超重附加 5 元","合计 13"])

主线(算运费)和旁线(记明细)在类型上分居:返回值是 (结果, 日志),测试时对日志断言就能验证决策路径——比 mock 一个 Logger 干净得多。注意 tell 的累积用的是第 6 章的 Monoid:日志类型换成 Sum Int 就变成「自动计步器」,换成 Map 就变成「指标聚合器」——旁路通道的语义跟着 Monoid 换,一套代码多种报表。工程提醒:真实项目里 Writer 出场率低于前两位(惰性累积容易攒 thunk,第 16 章的主题;高频日志走 IO 更实际),它的价值更多在心智模型:「返回值旁边挂一条 Monoid 通道」这个形状,在审计、计费、追踪场景里反复出现。

State 的经典案例:纯的随机数

State 还解决着一个你可能没意识到的老问题:随机数是副作用。Random.nextInt() 每次调用结果不同——它偷偷改了内部种子,是个如假包换的不纯函数。Haskell 的标准做法把种子摆上台面:

roll :: StdGen -> (Int, StdGen)          -- 吃种子,吐(点数, 新种子)
roll = randomR (1, 6)

-- s -> (a, s) —— 这形状我们刚见过!随机数生成天生就是 State:
rollThree :: State StdGen (Int, Int, Int)
rollThree = do
  a <- state roll
  b <- state roll
  c <- state roll
  pure (a, b, c)

-- evalState rollThree (mkStdGen 2026)  ⇒ 同一种子,永远同三个点数

红利立刻兑现:随机的测试可以复现了。「昨天那个诡异失败」只要记下种子就能一帧不差地重放——第 13 章 QuickCheck 的「种子复现失败用例」正是建在这上面;游戏回放、蒙特卡洛模拟同理。把「隐藏的可变量」显式化为穿线的状态,不纯就变纯——State 是这个手法的通用包装。

收束峡谷:一张速查表

五章的内容,一张表收拢——「分号之间发生什么」:

现在回望,Monad 的「难」基本是错觉的叠加:它不是一个东西难,而是七个简单东西共用一个接口——每个单看都平平无奇(你下游全用过),吓人的是「它们怎么会是同一个东西」。答案:它们的样板恰好都是「分号之间的固定动作」,而 >>= 恰好是给分号编程的钩子。就这样。