Functor 与 Applicative:抽象的台阶

Functor:把 map 的「列表」抠掉

你对 map 的理解是「对列表每个元素做变换」。现在做一个思维动作:把「列表」换成「上下文」——一个装着值的东西,可能是列表(装零到多个),可能是 Maybe(装零或一个),可能是 Either e(装一个或一个错误)。「保持上下文结构不变,只变换里面的值」这个能力,就是 Functor:

class Functor f where
  fmap :: (a -> b) -> f a -> f b

instance Functor Maybe where
  fmap _ Nothing  = Nothing        -- 空盒子:保持空
  fmap g (Just x) = Just (g x)     -- 有货:拆开、变换、装回

instance Functor [] where
  fmap = map                        -- 列表的 fmap 就是老朋友

λ> fmap (+1) (Just 41)
Just 42
λ> fmap (+1) Nothing
Nothing
λ> fmap length (Right "hello") :: Either String Int
Right 5
λ> (+1) <$> Just 41        -- <$> 是 fmap 的中缀写法,高频出场
Just 42

注意 class 头部的 f:它不是普通类型,是类型构造子——「还差一个参数才成为类型」的东西。Maybe 不是类型,Maybe Int 才是;Maybe 本身是个「类型级函数」。类型的类型叫 kind:普通类型的 kind 是 *,Maybe 的 kind 是 * -> *。Functor 是对类型构造子的抽象——这是 Java/Kotlin 泛型做不到的一步(它们没有高阶类型变量,这就是为什么 Kotlin 里写不出统一的 Functor 接口,Arrow 只能用编译期戏法模拟)。

卡壳时刻:函数掉进了盒子里

fmap 拿双参函数试试,看看哪里卡住:

λ> :t fmap (+) (Just 3)
fmap (+) (Just 3) :: Num a => Maybe (a -> a)

没报错,但看类型:得到一个 Maybe (a -> a)——盒子里装了半个应用了一半的函数(柯里化在此显形)。现在想把它用到 Just 4 上,fmap 无能为力:它的签名要求裸函数 a -> b,而我们的函数在盒子里。缺的那块拼图,签名一写出来就明白了:

(<*>) :: f (a -> b) -> f a -> f b     -- 盒装函数,应用到盒装值
pure  :: a -> f a                       -- 把裸值放进最平凡的盒子

这两个函数(加上 Functor 基础)构成 Applicative。连起来用,「盒子里做多参调用」的完整句式诞生:

λ> (+) <$> Just 3 <*> Just 4
Just 7
λ> (+) <$> Just 3 <*> Nothing
Nothing
λ> (,,) <$> Just 1 <*> Just 2 <*> Just 3     -- 三参也一样,链下去就行
Just (1,2,3)

读法从左到右:「用 (+) 去消化 Just 3 和 Just 4」。任何一环 Nothing,整体 Nothing——短路语义和上一章的铁路一致,但注意形状差异:铁路是串行依赖(下一站的输入是上一站的输出),这里是并列独立(三个盒子互不依赖,只是最后合体)。这个差异马上兑现成真实价值。

真实代码:表单校验的 Applicative 风格

data User = User { name :: Name, age :: Age, email :: Email }

validateName  :: String -> Either VError Name
validateAge   :: String -> Either VError Age
validateEmail :: String -> Either VError Email

mkUser :: Form -> Either VError User
mkUser f = User <$> validateName  (rawName f)
                <*> validateAge   (rawAge f)
                <*> validateEmail (rawEmail f)

三个独立校验,一行组装,类型严丝合缝:User 的构造子是 Name -> Age -> Email -> User,顺着 <$> 和 <*> 一路部分应用下去。这个句式在真实 Haskell 代码库里的出场率极高——JSON 解码、配置解析、命令行参数,凡是「多个独立来源拼一个结构」的地方全是它。

那么上一章泅渡第 4 题——收集全部错误——解决了吗?诚实回答:标准 Either 的 Applicative 还是短路的(第一个 Left 就返回)。但 Applicative 的形状已经把「并列独立」表达出来了,剩下只差换一个合并策略:社区的 Validation 类型(validation 包)与 Either 结构相同,唯独 <*> 遇到两个失败时不短路,而是用 Semigroup 把错误拼起来(第 6 章的 <> 在此上岗)。同一行 mkUser 代码,换个类型就从「报第一个错」变成「报全部错」——策略在类型里,不在业务代码里。这就是抽象台阶的意义:句式统一后,语义可以整体替换。

traverse:Applicative 的批量形态

上一章末尾的 sequence(把 [Maybe a] 翻成 Maybe [a])可以升级了。实战里你很少先造出 [Maybe a] 再翻转——通常是「拿一列原料,逐个做可能失败的加工,想要整批结果」。一步到位的函数叫 traverse:

traverse :: Applicative f => (a -> f b) -> [a] -> f [b]
--          「逐个加工,把所有盒子合并成一个装着列表的盒子」

λ> traverse validateAge ["18", "25", "30"]
Right [18,25,30]                       -- 全部成功,整批放行
λ> traverse validateAge ["18", "abc", "30"]
Left (BadAge "abc")                    -- 一个失败,整批失败

看签名里的 f:它只要求 Applicative——所以同一个 traverse,f 换成 Maybe 是「批量判空」,换成 Either 是「批量校验」,换成 IO 是「批量执行动作收集结果」(它就是你可能听过的 mapM),换成上文的 Validation 就是「批量校验且累积全部错误」。一个函数,吃遍所有盒子——这是高阶类型抽象的又一笔分红,也是 Haskell 老手口中「traverse 是标准库最好用的函数」的原因。Kotlin 的 Arrow 里它叫 traverse/traverseEither,Rust 里是 collect::<Result<Vec<_>,_>>() 的那记妙手——你见过它的马甲。