ADT 与模式匹配:让非法状态无法表示

积类型:你早就会了

定义一个「值的组合」,用 data:

data Person = Person String Int
--   ↑类型名   ↑构造子    ↑两个字段:名字、年龄

alice :: Person
alice = Person "Alice" 30

类型名和构造子(constructor)经常同名,位置不同不冲突:签名里出现的是类型,表达式里出现的是构造子。构造子本身是个函数——:t Person 给你 String -> Int -> Person,所以它也能柯里化、也能 map。字段多了用记录语法(record syntax),顺便白送访问器:

data Person = Person { name :: String, age :: Int }

λ> age alice
30

这类「A 和 B 都要有」的类型叫积类型(product type)。为什么叫积?数一数:(Bool, Bool) 有 2×2 = 4 种可能的值。字段的可能性相乘——data class、record、struct、tuple,全世界的语言都有积类型,没什么新鲜的。新鲜的是下一个。

和类型:被主流语言遗忘四十年的另一半

data Shape
  = Circle Double          -- 半径
  | Rect   Double Double   -- 宽、高

area :: Shape -> Double
area (Circle r)   = 3.14159 * r * r
area (Rect w h)   = w * h

竖线读作「或」:一个 Shape 要么是 Circle(带一个 Double),要么是 Rect(带两个)。可能性相加(是「圆的所有可能」加「矩形的所有可能」),所以叫和类型(sum type)。「和 + 积」凑齐了加法和乘法,「代数」数据类型由此得名——而且这个代数是真的能算的:

用第 1 章埋的伏笔开刀。网络请求页面的状态,布尔堆写法 vs ADT 写法,状态数差多少?自己按一按:

三个布尔字段能编码 8 种状态,业务只有 4 种合法——剩下 4 种(「既成功又失败」之类)靠代码评审和运气防守。每加一个布尔,非法状态翻倍。ADT 写法里,非法状态是 0:不是「被检查掉了」,是类型里压根没有那个格子。这就是「让非法状态无法表示」的字面意思。

模式匹配:解构与分派一步完成

ADT 是「造」,模式匹配(pattern matching)是「拆」。上面 area 的两个子句已经在用了:每个子句的参数位置写一个模式,运行时从上到下找第一个形状吻合的,同时把字段绑定到名字。表达式内部用 case:

describe :: Shape -> String
describe s = case s of
  Circle r | r > 100  -> "大圆"
           | otherwise -> "圆"
  Rect w h | w == h    -> "正方形"
  Rect _ _             -> "矩形"

几个高频武器:_ 通配(「有这一格但我不关心」);嵌套模式(Just (Rect w _) 一步拆两层);@ 别名(whole@(Circle r):既要整体又要零件);守卫和第 2 章一样可以挂在模式后面。

而全场最有价值的功能,是穷尽检查(exhaustiveness check)。开着 -Wincomplete-patterns(工程里必开),漏一个分支编译器立刻点名:

λ> -- 假设 Shape 新增了 Triangle,而 area 没改:
Shape.hs:12:1: warning: [-Wincomplete-patterns]
    Pattern match(es) are non-exhaustive
    In an equation for ‘area’: Patterns not matched: Triangle _ _

体会一下这个工作流:业务变化 → 改类型 → 编译器列出所有需要跟着改的地方。重构从「全文搜索 + 祈祷」变成「顺着报错清单走」。这是静态类型在业务代码里最实在的一笔回报。

Maybe 与 Either:明星也只是普通 ADT

第 8 章的两位主角,现在可以剧透它们的全部定义了:

data Maybe a  = Nothing | Just a
data Either a b = Left a | Right b

就这么多。没有魔法,没有关键字,没有编译器特判——「可能不存在的值」和「二选一的值」用和类型直接表达,是任何人都写得出来的两行。这是上游给你的重要一课:下游语言里那些「内置的、特殊的」东西(null 安全、Result),在类型系统足够好的语言里只是库代码。语言的进化方向,就是把魔法降级为库。

顺带认识 newtype:给已有类型穿一件零开销的新马甲,专治「三个参数都是 String,传反了编译器也不知道」:

newtype UserId  = UserId String
newtype OrderId = OrderId String

cancel :: UserId -> OrderId -> IO ()
-- cancel (OrderId "o1") (UserId "u9")  ← 现在这行直接编译不过

真实代码:把订单流程写进类型

ADT 建模的完整体是「状态 + 状态携带的数据」一起编码。看一个够真实的例子——电商订单,每个状态携带只有该状态才有的数据:

data Order
  = Cart      { items :: [Item] }                          -- 购物车:只有商品
  | Placed    { items :: [Item], orderNo :: OrderNo }      -- 已下单:多了单号
  | Paid      { items :: [Item], orderNo :: OrderNo
              , txId  :: TxId }                            -- 已支付:多了流水号
  | Shipped   { orderNo :: OrderNo, trackNo :: TrackNo }   -- 已发货:多了运单号
  | Cancelled { orderNo :: OrderNo, reason :: String }

refund :: Order -> Either String Refund
refund (Paid _ no tx) = Right (issueRefund no tx)
refund _              = Left "只有已支付订单可以退款"

对比常见写法——一个大而全的 Order 类,塞满可空字段(txId 可空、trackNo 可空、reason 可空),配一个 status 枚举,注释里写「txId 仅在 PAID 后有值」。那句注释就是漏洞:类型没拦着任何人在 CART 状态读 txId。而上面的 ADT 版本里,「购物车没有流水号」不是约定,是事实——那个格子根本不存在。refund 想拿 txId,就必须先匹配出 Paid,想跳过检查都没有语法可用。

还有一层保护给「造」的环节:智能构造子(smart constructor)。把裸构造子藏在模块里,只导出带校验的工厂函数:

module Email (Email, mkEmail) where     -- 注意:导出 Email 类型,不导出构造子

newtype Email = Email String

mkEmail :: String -> Maybe Email
mkEmail s = if '@' `elem` s then Just (Email s) else Nothing

模块外的世界不可能造出一个没有 @ 的 Email——不是「不应该」,是「不可能」:构造子没导出,想绕都没路。于是所有接收 Email 的下游函数,永远不必再校验一遍。校验从「每层都做、每层都不放心」收缩为「入口做一次、类型作担保」——这个模式叫 parse, don't validate,值得写进你任何语言的代码评审清单。