第一次给一门动态语言扩展静态类型时我犯了个很典型的错误先花了两周写漂亮的文法结果发现真正难的其实在文法背后那层晦涩的语义约束。后来我才慢慢想明白所谓“编程语言扩展的实现”重点从来不是“加一个关键字”而是“给类型系统补上一种新的判定能力”。类型系统不是一个语法糖盒它是一套可以证明程序不犯某些错误的逻辑框架而扩展它本质上是在往这套框架里塞进新的推导规则同时不让原有规则崩溃。这篇文章就把我实际做过的几次类型系统扩展经验拆开来讲从语义设计、内部表示、检查器流水线到真实踩坑尽量说透。文章面向想自己搞一门 DSL、给解释器加类型注解、或者正在写编译器前中端的朋友。我会假设你写过递归下降解析器、理解 AST、知道什么是作用域和变量绑定但不要求你是 PL 理论专家。所有公式都尽量避免能用手工算法说清楚的绝不上形式化符号。1. 类型系统扩展到底在扩展什么三个能力缺口动工之前要先分清“类型系统能做什么”和“我们需要它做什么”。很多人把扩展等同于“让类型检查器多认识一种类型”这是片面的。类型系统扩展本质上是在补齐三个能力缺口表达力、检查力、工具链支持。1.1 表达力缺口动态值需要静态边界表达力缺口是指语言现有的类型表达手段无法描述你想表达的约束。举个例子随手写一个路由配置脚本route(/users/{id}, handler)如果现有类型系统只有int、string、list那么handler这个参数只能被声明成“函数”或“对象”你没法告诉编译器“这个函数必须接收一个 mapmap 里的id是整型”。于是用户只能在运行时自己防御。补表达力的典型手段包括泛型参数、联合类型、交叉类型、依赖类型、行多态、类型族等。你选取哪一种取决于你希望编译器在静态阶段拦住多少运行时错误、以及你的解析器和检查器复杂度天花板在哪里。我从实际项目里得到的体会是表达力扩展的复杂度曲线是断崖式上升的。加一个简单的联合类型例如string | int很便宜但一旦你要让联合类型参与泛型推断立刻就要处理逆变、协变、分配律等一系列问题。所以在立项前必须想清楚哪一级表达力是当前业务真正需要的。1.2 检查力缺口规则需要可判定检查力缺口则更隐蔽。很多类型约束其实是可表达的但你现有的检查器不支持对应的判定过程。最常见的例子是 null 安全性表达上你只要能写出string | null就能描述可空值检查上你需要推导“某个值在这个分支里一定不是 null”这需要控制流分析。如果你扩展了一个语法却没有扩展对应的检查算法那这个扩展就是一张空头支票。用户会写出明显有问题的代码类型系统却一声不吭或者更糟误报一堆错误的错误信息。我建议在动手前写一份“判定清单”对每一种新增语法写出它的验收用例包括合法用例、非法用例、边界用例。这比任何设计文档都更能暴露问题。1.3 工具链缺口报错、推导、重载第三个能力缺口最容易被低估类型系统不是孤立运行的它要跟报错、自动补全、重载解析、推导联动。一个扩展如果无法生成指向源码位置、可读性强的诊断信息那就算判定逻辑完全正确用户也会觉得它“很蠢”。比如你给语言加了 sum type和类型模式匹配的穷尽性检查如果报错信息只写一句“缺少一个分支”用户根本不知道怎么补。好的报错要指出哪个类型形状没有被覆盖、对应的样板代码应该长什么样、在源码的哪一行开始漏掉的。所以在设计扩展时我习惯把“错误信息模板”当作一等任务来写每个新规则至少要配一个“你写错了系统怎么告诉你”的样例。这一点放到后面实操部分会详细展开。2. 类型扩展的契约设计先写语义再写语法很多初学扩展的朋友习惯反着来先定义新关键字再琢磨它到底什么意思。好了等你进入检查器实现阶段你会发现自己被一堆模棱两可的语义细节卡住。正确的顺序应该是先写语义契约这个新类型在类型环境里是什么形状它和已有类型如何比较它参与推导的规则是什么2.1 新类型的文法设计虽然我说“先语义再语法”但语法依然是入口。在设计文法时有一个贯穿始终的原则新语法必须能稳定地映射到一种类型表达式不产生二义性。以联合类型为例常见文法有三种文法风格示例优点缺点中缀竖线string | int直观类 TS 用户零成本和位运算冲突的场合要处理优先级关键字联合union { string, int }无需改表达式优先级稍啰嗦类型别名type U string | int复用性好需要额外的环境绑定逻辑我给一个小 DSL 做扩展时选了中缀竖线因为它的目标用户是从 TypeScript 转过来的学习成本最低。但我吃了优先级转换的亏语言原来的|是位或运算而我又不想在表达式层引入新的上下文区分。最后决定只在“类型上下文”里允许|作为联合类型而类型上下文和表达式上下文在解析器里本来就被严格区分所以优先级冲突被消解了一大半。2.2 亮度解析与作用域模型的耦合类型扩展一旦涉及别名、泛型参数就绕不开作用域解析。你必须回答类型名称是在哪个作用域里被解析的它能不能引用普通变量它能不能与运行时值重名我在实践中的做法是给类型名单独维护一套TypeEnv类型环境与Env普通值环境完全分离。理由是类型系统是编译期结构允许类型名引用运行时值会让检查器被迫嵌入求值器复杂度爆炸。如果你真的需要“运行时值决定类型”依赖类型的雏形那最好是走单独的特判路径而不是把它做成通用机制。分离 TypeEnv 之后作用域规则反而好写了类型别名遵循和普通变量相同的词法作用域规则但它有自己的命名空间。这样用户能写出类似如下的代码而不会把编译器绕晕type Id int type Entity { id: Id, name: string }2.3 类型推断的边界决定新扩展是否要参与类型推断这是最影响工作量的问题。如果新类型只做显式注解那检查器只需要做“验证”也就是把注解拿下来和实际表达式比对工作量大减。一旦参与推断你要考虑联合类型的归一化string | string要不要折叠成string泛型调用时联合类型是否展开Liststring | int是否合法null 合并时如何收缩类型x ?? y的类型是T | U还是T。我的建议是从“只做显式检查”起步跑通整条链路后再逐步开放局部推断。很多语言扩展项目最后烂尾就是因为一开始就放开了推断不得不处理大量 corner case。这里的实操价值在于契约文档里必须有一条名为“推断策略”的章节写明三个层次——完全不推断、局部推断、全量推断并指定这个扩展当前符合哪一层。别模糊模糊就是将来加班。3. 内部类型表示把语义变成可以求解的数据结构类型系统的运行时也就是检查器内部对类型表达式的表示方式决定了所有后续算法的复杂程度。这块没设计好越往后扩展越痛苦。我把几种常见内部表示对比一下再讲选择逻辑。3.1 三种内部表示方案第一类直接把语法树节点当类型。解析出一个UnionTypeNode检查器遍历它做判断。优点是不用做任何转换缺点是无法表达注销后的结果、无法加入缓存、无法区分“用户写的类型”和“规范化后的类型”。第二类结构化类型表示。所有类型被规范化为少数几种节点IntType、StringType、FunctionType(paramTypes, returnType)、UnionType(members)等。这是绝大多数编译器的选择。第三类图或约束系统表示。类型被表达为节点和约束边组成的图求解过程在图上跑拍合一。适合复杂推断但性能调优难度高。我实际用第二类因为它的可调试性最好。我可以把一个表达式解析出的类型低成本地打印出来这在定位 bug 时非常爽。3.2 拍合与等值判断的细节有了结构化表示以后扩展类型的等值判断和拍合规则就必须立刻落地。所谓拍合(unify)就是“让两边类型互相兼容”的过程它负责决定string类型的变量能否接收string | int的值。我的实现里有一个unify(a, b, ctx)函数它返回一个替换表或拍合失败信息。对于普通类型它递归比较子组件对于联合类型它要拆开做逐成员兼容对于泛型参数它产生一个待求解的类型变量。这个瞬间你就会发现联合类型一旦出现等值判断就不再是简单递归了。你需要先对成员做排序和去重例如把int | string和string | int视为同一类型否则缓存会频繁失效、报错也会莫名其妙。3.3 泛型特化的展开时机如果你的扩展包含泛型多半绕不开还需要决定泛型特化的时机。我试验过两种检查期特化在类型检查阶段就把泛型参数替换成具体类型后续流程看到的都是特化后的类型。好处是简单坏处是会产生大量重复类型节点内存压力大。惰性特化保留泛型定义在需要检查某个调用时才把参数代入。好处是节省节点坏处是每次比较都要重新做代入CPU 压力转移。我的选择是检查期特化加一层类型缓存。每个泛型实例对应一个键(GenericDefId, [具体参数列表])检查器看到同一个键直接复用结果。这个缓存对性能提升非常明显尤其是嵌套泛型出现的时候比如ResultListUser, Error这种三层嵌套。generic_cache {} def instantiate(def_id, arg_types): key (def_id, tuple(arg_types)) if key in generic_cache: return generic_cache[key] body expand_body(def_id, arg_types) generic_cache[key] body return body这段实现相当直接但有两个隐藏问题一是缓存必须在不同模块编译之间保持一致否则同一泛型类型在不同文件里被解析成不同结构跨文件调用就对不上二是递归泛型会绕过缓存导致无限展开需要在 instantiate 里加一个深度计数器超过阈值就报告“超递归”错误。4. 把新规则焊进既有类型检查流水线扩展类型系统并不意味着推翻旧检查器。大多数项目的情况是已有解析器、已有 AST、已有检查器需要在它们身上动手术。这时候最讲究的是流水线组织方式。4.1 检查器的分层设计我习惯把检查器拆成四个阶段绑定阶段把作用域里的名称解析成定义项建立Symbol表类型收集阶段遍历所有带显式类型注解的节点转为内部类型表示并注册约束生成阶段对表达式生成类型约束例如a b要求a和b都是数值类型约束求解阶段拍合、推导并输出最终类型。新增扩展时原则上只改第三个和第四个阶段绑定阶段基本不动。这样做的最大好处是如果新扩展坏了你可以把问题快速定位到“约束生成逻辑”而不是整个检查器。4.2 用“规则表”替代满地的 if else很多检查器用大量if node.kind BinaryExpr来分发逻辑。项目小的时候没问题一旦要支撑多套扩展这种写法会变得无法维护。我建议在约束生成阶段引入一个规则表每个 AST 节点类型对应一个ConstraintProducer。register_producer(UnionTypeExpr, union_producer) register_producer(MatchExpr, match_producer) register_producer(TypeAliasStmt, alias_producer)规则表的好处是新增扩展时可以完全不动既有规则只往表里插一条新记录。接口形如def union_producer(node, ctx): member_types [resolve_type(t, ctx) for t in node.members] return UnionType(member_types)这种设计本质上是一种访问者模式的变体但通过表格切分了关注点。我后来在好几个项目里反复用同一套思路不管扩展多少检查器主干都保持稳定。4.3 两阶段解析解决“前向引用”问题类型扩展最常见的一个炸点是类型之间的前向引用。比如类型A引用B而B又定义在A后面。如果你一边扫 AST 一边立即解析类型名必然会在解析A时找不到B。解决方案是两阶段解析第一阶段只登记所有类型声明的名称和形状骨架第二阶段再真正解析类型内的引用。这就像办户口先登记人口再填家庭关系否则你没法处理“我爸爸是谁”的问题。# 第一阶段收集 for decl in ast.type_decls: type_registry[decl.name] TypePlaceholder(decl) # 第二阶段展开 for decl in ast.type_decls: expand_type(decl, type_registry)很多朋友写扩展时沿用单个遍历函数直接递归解析类型名结果遇到递归类型声明就直接爆栈。用两阶段解析之后不仅前向引用解决了递归类型如type Tree { value: int, children: ListTree }也自然获得了有限容身之地——前提是你在展开阶段检测递归深度。注意两阶段解析不等于延迟报错。第二阶段如果遇到未登记的类型名要立刻给出“类型未定义”的错误不要等到约束求解阶段才报否则用户看到错误位置会离真实问题十万八千里。5. 实操给语言加 sum type 并实现穷尽性检查前面讲的是方法论这里拿出一个完整小项目来走一遍。目标语言很迷你只有整数、字符串、布尔、函数和列表。我们要给它扩展 sum type 和模式匹配并且要求模式匹配必须穷尽不能漏分支。这个项目我完整做过下面按阶段拆解每个阶段都能跑。5.1 阶段一语法与 AST 扩展首先定义 sum type 的语法。我选的是枚举式风格type Shape | Circle(radius: int) | Rectangle(w: int, h: int) | Point对应的 AST 设计分三个新节点TypeDeclNode(name, variants)整个 sum type 声明VariantNode(name, fields)其中一个分支fields 为空就是无参变体MatchNode(scrutinee, cases)模式匹配表达式。解析器这边新增一个parseTypeDecl在遇到type关键字时进入新增parseMatch在遇到match关键字时进入。优先级上match作为表达式会与函数调用发生嵌套我用 Pratt parsing 把它当一元前缀运算符处理最低优先级。5.2 阶段二类型表示与注册内部类型新增一个SumType(variants)节点它包含一个从变体名到字段类型的映射。同时我引入了类型注册表维护“变体名”到“所属 SumType”的全局映射因为模式匹配分支是通过“变体名”来命中分支的它可能出现在与声明相距很远的代码里。class TypeRegistry: def __init__(self): self.sum_types {} # name - SumType self.variant_owner {} # variant_name - sum_type_name注册时机是在两阶段解析的第一阶段捕获此时Circle、Rectangle、Point会登记进variant_owner。5.3 阶段三分支穷尽性检查穷尽性检查是本次扩展中最有技术含量的部分。它要求match表达式的分支覆盖Shape的所有变体。算法可以分成三档复杂度第一档逐变体检查covered set() for case in match.cases: if case.pattern.is_wildcard(): return OK covered.add(case.pattern.variant_name) missing set(registry.variant_owner[scrutinee_type].keys()) - covered这一档代码简单缺点是无法处理“变体携带子结构”时的嵌套模式匹配。不过作为 v1 已经够用。第二档对带字段的变体做子穷尽检查。比如case Circle(radius) ... case Circle(area?) ...你可能需要覆盖Circle的所有字段组合这会变成每个变体内部的乘积计算。第三档支持守卫(guard)条件下的穷尽分析。这个很复杂常规做法是把守卫当成“覆盖但不可证明”也就是宁可报告“可能不穷尽”也不做过度推断。我在该项目里做到第一档部分第二档已经能捕获绝大部分漏分支场景。实现中发现对Point这种无参变体只需把分支名加入集合对Circle(radius)这种带字段变体只要变体名出现就算覆盖字段级检查放到下一阶段实现。5.4 阶段四模式匹配的类型核对除了穷尽性match的每个分支还需要核对模式里声明的变量类型是否与变体字段类型一致。再拿Circle(radius)举例如果radius被推断为int但变体字段其实声明为string那检查器就要报错。实现方式不复杂拍合函数的unify(typename, pattern_var_type)。注意两点无参变体上若写了变量要报告“这个分支不接收变量”模式变量不能与变体名冲突。这一阶段还顺带完成了“不可达分支”检测如果匹配顺序里前面的分支已经用通配符_全部覆盖后面的具体分支就是不可达的可以给出警告。5.5 阶段五生成可读的报错最后一定要打磨报错。我当时的模板长这样error[E1001]: match not exhaustive -- src/demo.txt:12:5 | 12 | match s { | ^ missing variants: Point | help: add a case for Point: | Point { ... } |补全建议直接写进报错里这特别重要。用户不需要翻手册才知道怎么修。我自己测试时的感受是如果报错缺了help一行用户可能盯着屏幕五分钟不知道该怎么写。注意生成 help 时要基于当前已覆盖的分支自动拼出缺失分支的样板而不是写死文本。否则一旦 sum type 定义变化报错内容就会过期。6. 我踩过的五种“扩展失败”的真实场景这个部分本来不想写但实在踩坑太多必须给后来人留点路标。每种场景都对应一次真实的加班经历你能避开一个就值回票价。6.1 递归 SumType 的无限展开第一次给 sum type 支持递归我天真地允许type Json { obj: map | values: ListJson }。结果检查器在展开时无限递归进程直接 OOM。后来加了一层“展开深度计数器”不仅在泛型特化里用还在所有递归类型展开里用。达到阈值就报错不要闷头展开。6.2 模式匹配与子类型的相互作用当 sum type 内部用到了联合类型严格说 sum type 和 union type 不是一回事穷尽性检查的集合运算会膨胀。比如type Shape | Circle | Rectangle type Polygon Circle | Rectangle # 等价但不同名如果你在穷尽检查里没有做标记集合并集运算就会出现“明明覆盖了所有变体还报错误”的假阴性。解决办法是穷尽检查前先把模式中出现的类型统一转换成规范化形式再做集合比较。6.3 报错定位到生成代码而非源码在某些扩展里新的检查逻辑会降级为等价旧代码再检查。这种降级容易让错误位置指向“生成后的代码”而不是用户手写的源码。务必在生成过程中保留一个SourceSpan穿透结构让报错坐标始终指向原始源码。这个坑很隐蔽因为单测里用短代码很难触发一旦用户写上几百行代码错位感会非常明显他们会觉得“这个编译器疯了”。6.4 类型缓存与模块重新编译的冲突前面提到过 generic_cache这里重点说一下失效时机。IDE 场景里用户编辑一个文件后编译器往往只增量编译被改动的部分。如果你的缓存放在单次编译的全局变量里旧文件的部分类型节点会残留新文件拿到的缓存可能是脏的。我最后采用的方案是给缓存加一层“文件修订号”维度的键每次文件保存就递增 revision缓存键里带上 revision。这样既保留了复用又不会在增量编译时读到旧数据。6.5 类型别名缺一层“命名保护”这个坑在高级场景会遇到。如果你允许用户给类型起别名但别名展开时没有保留原始名称报错会变得极难阅读。例如type ID string type Name string如果拍合失败你希望用户看到的是“期望 Name实际得到 ID”而不是“期望 string实际得到 string”。为了实现这一点我保留了别名包裹层检查器在报错时只剥开最外层Alias(name, inner)把inner作为结构依据name作为展示依据。7. 扩展工作的取舍判断什么情况下该停手并不是所有类型的缺陷都需要靠扩展解决。我在项目后段经常提醒自己类型系统扩展是带杠杆的手术刀用对了收益巨大用错了会让整个语言变得难以学习、难以检查、难以维护。一个重要判断标准是新增语义能不能用现有原语组合出来。如果能那它大概率不该成为一等扩展。比如“可空类型”本质上就是T | null的联合类型你没必要单独造一个NullableT但如果你希望null参与运算时自动报错那才需要单独的控制流分析规则。另一个判断标准是编译器有没有能力给这个扩展生成“让人一眼看明白”的诊断。如果你试写了报错模板之后发现怎么也说不清楚那这个设计的语义本身就太绕了砍掉重设计比重写实现更划算。还有一个经济性标准改动范围能不能控制在检查器内部如果扩展要求你同时改语法、解析、作用域绑定、求值器和 IDE 插件那么它带来的维护成本可能远超过收益。除非是语言的核心特性否则我建议暂缓。最后再分享一个实操小技巧给类型系统做扩展无论如何要先准备一套“最小回归测试集”我一般只放五个用例——合法用例、非法用例、边界用例、递归用例、跨模块用例。每改一次检查器就跑一遍跑不过就立刻修。这套测试集存在成本很低但它会在后续几个月里不断救你的命尤其是当你同时维护多个扩展时它能第一时间告诉你到底是哪一个改动破坏了哪一条规则。项目的结束不是类型检查器跑通了所有用例而是你能自信地删掉两处临时补丁的那一天。类型系统扩展是一场对语言规则的重新定价你每加一条规则都在决定这门语言愿意为哪种正确性买单。别让这笔买卖亏本。