在 PLT 里，你既是规则的制定者，又是规则的囚徒： 设计一套语言之后，必须接受自己设计出来的一切后果， 包括那些在设计时根本没想到的交互． 这种“造物”与“遭造物反噬”之间的张力，对我有很强的吸引力． 别的工程把抽象当作工具，PLT 则把抽象本身当作研究对象．

语言设计的第一步，往往是决定“我要哪些特性”． 这一步很像做排列组合：你希望某些特性之间发生奇妙的化学反应， 或者为了专攻某个方向而特意引入某些特性， 例如 Rust 的仿射类型与生命周期、Haskell 的类型类、Lisp 的宏． 把这些特性两两摆到一起，大致会看到几类关系．

正交的特性彼此独立，可以放心叠加． 例如词法作用域与垃圾回收、闭包与模式匹配、泛型与模块系统； 它们各自解决不同维度的问题，组合起来几乎不产生额外语义． 协同的特性单独看平平无奇，合起来却能涌现出新能力： 闭包与 GC 让高阶函数变得廉价， 类型类与单态化让“零成本抽象”成为可能， 模式匹配与广义代数数据类型（GADT）支持类型安全的结构化求值， 代数作用与定界续延让“可恢复的计算”成为一等公民． 这类组合是设计语言时最值得追求的东西．

冗余与重叠出现在同一个目的有多种相互重叠的表达方式时， 硬塞在一起就可能让语言出现“两套并行的世界观”． 例如 Monad 与代数作用处理器都可用于建模与组织副作用： Monad 通常以库抽象的形式组织计算， 代数作用处理器用处理器解释作用操作； 后者既可以作为语言特性，也可以编码成库，两者在语义上有紧密联系． 再如异常与 Result Result / Either Either 、 null null 与 Option Option 、类与类型类、宏与泛型． 冗余本身不致命，但它会让用户不断面对“我该用哪个”的选择疲劳， 也会让两套机制的交互成为缺陷的温床， 因为任何一处改动，都得把所有组合重新考虑一遍．

冲突的特性单独看都很好，放到一起却语义打架，或者直接导致理论上的不可判定． 例如子类型与多态、类型推理的组合会增加复杂度， 某些具体系统存在不可判定性，但仅凭子类型与记录或列表并不能推出这个结论； MLsub 与 Simple-sub 就支持子类型、记录和 ML 风格的全局类型推理． 又如类型推理加特设重载会让“最具体实例”的选择变得病态； 宏如果不满足卫生性，会污染调用处的作用域； 线性类型与“可随意复制”的默认语义天然对立． 面对这类组合，往往只能取舍，难以调和．

依赖指特性 B 的成立以特性 A 为前提． 例如 GADT 模式匹配需要能处理局部类型相等约束的检查规则，实际实现常借助显式标注； 高秩多态类型不同于高阶类型构造子，在 GHC 等实现中通常需要标注提供多态参数的类型． 若希望依值类型承担可信证明，并保证类型检查中的计算终止， 就需要限制相关递归或验证其终止性，但不必要求所有程序都终止． async async 与 await await 则需要支持挂起与恢复的机制： 状态机变换是常见实现方案之一，也可以借助续延传递风格（CPS）、栈式协程或作用处理器． 识别真正的依赖关系、区分它们与实现选择，才能排出合理的实现顺序．

此外还有不可组合的情况：两套机制根本不在同一套假设下， 例如一等续延与某些 C 外部函数接口（FFI）的栈约定．

选好特性只是开始． 真正的复杂度来自交叉点：$𝑛$ 个特性最多有 $𝑛\left(𝑛-1\right)/2$ 个两两交互， 数量只是二次增长； 如果考虑所有包含至少两个特性的子集，则共有 $2^{𝑛}-𝑛-1$ 种可能组合， 数量是指数增长的． 组合数量并不等于实际设计复杂度，还要看哪些特性真正发生交互． 你在设计 A 和 B 时都想到了各自的情况， 却没想到 A 的某个角落和 B 的某个角落会撞在一起．

盲点很难在纸面上直接看出来，往往要靠几种实践暴露： 做形式化，写出操作语义，或者在 Coq（现名 Rocq）、Agda、Lean 里做机械化证明，代价最高，也最彻底； 写测试，像 WebAssembly 的规格测试那样用大量程序去撞边界； 亲自自用，拿这门语言写非平凡的程序，乃至自举，把“设计者视角”换成“用户视角”； 或者动手实现原型编译器，让类型检查器和求值器替你发现矛盾．

发现盲点之后，处理手段也集中在几条路上． 可以直接限制，禁止出问题的组合，例如规定“泛型不能作为数组长度”，用报错换一致性； 可以做规约，把一种特性脱糖成另一种，只保留一套语义内核，例如把 for for 脱糖成 while while 、把 async async 脱糖成状态机； 可以分层，把两套机制放到不同的层级，规定谁能看见谁，例如把宏展开限定在编译期，把作用的静态描述与检查放在作用系统里，再由生成的代码或运行时机制实现对应行为； 也可以引入新构造，承认已有特性不够表达，加专门的正交构造来承担交叉点； 还可以限制自动推导，要求必要的类型标注以采用可判定的检查算法；若检查或子类型判定本身不可判定，则标注也未必能解决，必须另行说明限制哪些规则、如何处理无法完成判定的输入．

发现并处理这些盲点，基本上就是 PLT 研究的日常，也是语言设计复杂度的来源．

这一层包含所有与“人怎么写、机器怎么读”有关的设计： 具体语法与抽象语法、运算符优先级与结合性、 缩进与换行规则、语法糖、宏与卫生性、错误恢复．

语法层看起来浅，却很容易积重难返： 随手加的语法糖，可能会让后续所有解析都变得含混． 经验法则是：让语法糖尽量可脱糖； 每引入一种简写，都要能说清楚它脱糖后的核心形式是什么．

这一层包含从抽象语法树（AST）到字节码之间的所有表示及其转换： 脱糖、A-正规形式（ANF）、CPS、静态单赋值形式（SSA）、 三地址码、闭包转换、单态化、内联、优化遍．

中间表示（IR）的设计与降级流程会深刻影响语言实现： 惰性求值常用延迟块（thunk）或闭包实现，但不要求每一级 IR 都保留显式的节点； 保证尾调用不增长调用栈，需要编译流程与目标平台的配合； 可恢复的作用处理器需要相应的续延或挂起与恢复机制， 而普通的状态修改、I/O 等副作用不需要这样的机制． 许多语言最终卡在从核心语义到低层代码与运行时的转换上，问题并不出在语法或类型系统． IR 正是落实语言语义的桥梁．

“类型系统”只是这一层的一部分，所以我更愿意叫它检查系统． 它负责拒绝那些不该通过的程序，通常在编译期完成，必要时也可以推迟到运行时． 常见的类型系统有 Hindley–Milner（HM）、F 系统、依值类型、线性与仿射类型、精化类型； 实现时可采用双向类型检查，这是一种检查的组织方式，与 F 系统这类演算分类处在不同维度． 作用系统处理作用标注、作用行、作用多态等； Monad 可用于建模作用，代数作用处理器是解释作用操作的机制，两者不等同于静态作用系统， 有处理器的语言也未必静态跟踪作用（例如 OCaml 不静态保证所有作用都得到处理）． 此外还有 Rust 那套基于区域与借用的所有权与借用检查、 全函数式编程一脉的终止性与全域性检查， 以及针对纯度、可序列化性、并发安全性等性质的静态检查．

这一层始终在表达力、可推导性、错误信息的可读性与实现复杂度之间取舍，四者很难同时兼顾．

这一层包含程序跑起来时的一切： 内存管理（GC、自动引用计数 ARC、区域等）、副作用管理、 求值策略的实现（按值调用、按需调用、按名调用）、并发与并行模型、 FFI、解释执行与 JIT． 提前编译（AOT）是运行前的编译方式，属于编译流程； 它生成的代码仍可能依赖运行时支持． 线性与仿射类型则是静态约束，可以帮助编译器安排资源释放，自身并不充当运行时内存管理算法．

在我看来，这一层最工业化、最繁杂． 入门课程会覆盖其中一些概念，但生产级运行时的工程细节很难在一门课里讲透； 它也是决定一门语言能否落地的重要因素．

如果目标是设计一门自己用起来很舒服的编程语言，可以按这样的顺序推进： 先从语法开始，不必急着上手写解析器，先用 ANF 的形式把核心语言的语法与求值规则写清楚；ANF 把求值顺序显式化，让你没法用“反正运行时知道”来糊弄自己． 接着选定 IR，沿着“树遍历解释器 → ANF / CPS → 字节码”的路线先跑通再优化，不必一上来就做 SSA． 类型系统可以从简单类型 λ 演算起步，先把双向类型检查写顺，作用系统留到后面再碰． 最后在后端与宿主运行时上尽量复用成熟的基础设施，同时明确记下仍需自己实现或适配的语言语义与运行时支持．