企业官网建设流程全解析

• 编程语言
• 编译器
• 语言运行时
• 开发工具

Unison 语言中的 Record（记录类型）是一类以花括号{ ... }声明字段的数据类型，编译器会自动为每个字段生成get / set / modify三个访问器函数。本文以仓库中的幂等性测试脚本 records.md 为核心，讲解如何验证「记录类型加入代码库后语法保持不变」，并深入 DeclParser.hs、DeclPrinter.hs 与 Records.hs 源码，说明字段分隔符、尾逗号、自动访问器生成等机制背后的实现原理。读完本文，你将掌握：用 UCM 转录测试验证 Record 语法往返一致性的完整方法，以及 Record 访问器在解析器与打印机中的真实生成逻辑。

一、测试脚本概览：转录测试如何验证语法保真

该文档是unison-src/transcripts/idempotent/目录下的一组幂等转录测试（idempotent transcript test）。转录测试（Transcript）是 Unison 项目用来驱动 UCM 命令行交互的自动化脚本格式，由 Markdown 与unison/ucm代码块构成，unison-src/transcripts/idempotent/中的用例要求多次执行结果保持一致（幂等）。

脚本开头先初始化测试环境：

> builtins.merge > load unison-src/transcripts-using-base/base.u

• builtins.merge将内建类型与函数合并进当前代码库，供后续用例使用；
• load unison-src/transcripts-using-base/base.u加载位于 base.u 的基础库定义（如Exception、Either相关工具函数），为用例提供可引用的类型环境。

ucm :hide表示该代码块的输出在最终转录结果中隐藏，仅保留有:show或普通ucm标记的代码块输出。测试的核心思路是：先用unison代码块声明一个 Record 类型，再通过add将其加入代码库，最后用view命令重新打印该类型，并对比打印结果与原始声明是否一致。若语法在「解析 → 入库 → 重新打印」的往返（round-trip）过程中发生任何改变，则测试失败。

二、逐级字段数的 Record 往返验证

2.1 单字段 Record

unique type Record1 = { a : Text }

经add入库后执行> view Record1，UCM 输出：

> view Record1 type Record1 = { a : Text }

声明与打印结果完全一致，单字段 Record 语法保真通过。

2.2 双字段与三字段 Record

unique type Record2 = { a : Text, b : Int } unique type Record3 = { a : Text, b : Int, c : Nat }

对应的view输出同样与源码一致：

> view Record2 type Record2 = { a : Text, b : Int } > view Record3 type Record3 = { a : Text, b : Int, c : Nat }

这里同时覆盖了Text、Int、Nat三种常见内建类型的字段声明。

2.3 多字段 Record 的换行与逗号处理

当字段数量增多、源码换行书写时，往返行为出现关键差异——打印结果会把所有字段合并到单行：

unique type Record4 = { a : Text , b : Int , c : Nat , d : Bytes , e : Text , f : Nat , g : [Nat] }

view Record4输出：

> view Record4 type Record4 = { a : Text, b : Int, c : Nat, d : Bytes, e : Text, f : Nat, g : [Nat] }

可见打印机采用「每行一个字段、逗号位于字段名后方（trailing comma 风格）、首行{ a : Text,与末行}收尾」的固定布局，字段顺序保持不变。

2.4 大量字段（20 字段）Record

Record5声明了 20 个字段，字段类型为层层嵌套的[Nat]列表类型，用于验证打印机在极端规模下的行为：

unique type Record5 = { zero : Nat, one : [Nat], two : [[Nat]], three: [[[Nat]]], -- …（略） twenty: [[[[[[[[[[[[[[[[[[[[Nat]]]]]]]]]]]]]]]]]]]] }

view后每个字段依然保持独立一行，嵌套类型逐层保留，证明：

• 字段数量不影响 Record 语法的往返一致性；
• 嵌套的[Nat]类型括号层级在打印时被完整保留，不存在括号丢失。

2.5 字段类型为用户自定义类型的 Record（已知 Bug）

测试脚本特意覆盖了一个「看起来像 Record、实际打印时却退化为普通构造器」的边界情况：

unique type UserType = UserType Nat unique type RecordWithUserType = { a : Text, b : Record4, c : UserType }

脚本注释明确写道：对RecordWithUserType执行view或edit时，它应该被当作 Record 类型处理，但实际并没有——这是一个 Bug：

> view RecordWithUserType type RecordWithUserType = { a : Text, b : Record4, c : UserType }

从当前输出看，打印结果仍然保留了花括号形态。但注释揭示了一个关键约束：Record 识别依赖于「自动生成的访问器名称是否能从代码库的名字空间中反查得到」（详见第三节源码分析）。当字段类型是用户自定义类型、或访问器因哈希/名字查询失败时，声明就可能不再被视为 Record。该用例的价值在于把这种退化场景固化进测试，防止未来修复回归。

三、源码纵深：Record 是如何被识别与打印的

3.1 解析端：{ ... }字段列表的语法规则

Record 声明的语法解析位于 DeclParser.hs 的synDataDeclP中。其record解析器（第 125-137 行）规则为：

record = do _ <- openBlockWith "{" let field = do f <- liftA2 (,) (prefixVar <* reserved ":") TypeParser.valueType optional (reserved ",") >>= \case Nothing -> pure [f] Just _ -> maybe [f] (f :) <$> (optional semi *> optional field) fields <- field closingToken <- closeBlock ...

要点：

• 字段语法：字段名 : 类型，字段名需为合法的相对变量名（prefixVar），类型交给TypeParser.valueType解析；
• 分隔符：字段之间使用,，允许尾逗号（每个字段后的逗号是optional，即可有可无），也允许,后跟换行（optional semi处理分号与换行）。这正是文档「Syntax：尾逗号是允许的」一节所验证的行为；
• 解析成功后，SynDataDecl的fields字段被填充为Just fields，与普通构造器语法的Nothing区分开（第 176-187 行）。

3.2 打印端：如何判断一个类型「看起来像 Record」

打印端的关键函数是 DeclPrinter.hs 中的getFieldAndAccessorNames（第 253-332 行）。它判断某个数据类型声明是否应该按 Record 形式打印，算法如下：

1. 单构造器检查：Record 恰好只有一个构造器（[(_, typ)] <- Just (DD.constructors dd)）；
2. 生成访问器：为每个字段按_0, _1, ...生成get/set/modify对应的访问器项，调用DD.hashFieldAccessors计算这些访问器项的哈希；
3. 名字反查：用PrettyPrintEnv（PPE）把这些访问器的哈希反查为代码库中的名字，例如Pt.x、Pt.x.set、Pt.x.modify；
4. 字段名回推：从类型名.字段名的名字中剥离类型名前缀，还原出字段名；若所有访问器都成功反查且字段名数量与访问器数量一致，则判定为 Record（第 319-332 行），打印成{ 字段 : 类型 }布局；否则返回Nothing，退回普通构造器打印。

源码注释（第 262-263 行）明确给出一种退化情形：当声明在代码库中只有哈希、没有可解析的名字时，无法定位访问器所在的名字空间，因而放弃 Record 识别。这与 2.5 节RecordWithUserType用例注释「它应该被当作 record 类型，但它没有（这是一个 bug）」形成了呼应——识别逻辑对名字环境敏感，存在已知边界缺陷。

view命令本身在 InputPatterns.hs（第 912-936 行）中定义：view foo打印当前名字空间内名为foo的定义，支持?通配符 glob 语法；对 Record 的打印正是经由上述prettyDecl/getFieldAndAccessorNames路径完成的。

3.3 访问器的真实生成：get / set / modify 三件套

Record 之所以能打印回{ ... }形式，前提是代码库中存在配套的自动访问器。这些访问器由 Records.hs 的generateRecordAccessors生成，hashFieldAccessors（Dependencies.hs 第 81-148 行）负责对它们做类型检查并哈希：

• getter：point -> case point of Point _ y _ -> y，即模式匹配取出对应字段；
• setter：y' point -> case point of Point x _ z -> Point x y' z，重建构造器并替换目标字段；
• modifier：f point -> case point of Point x y z -> Point x (f y) z，对字段施加函数变换。

每个字段都会生成形如Record5.a、Record5.a.set、Record5.a.modify的三个名字（见文档中:added-by-ucm输出块：+ Record5.a : Record5 -> Text、+ Record5.a.modify : (Text ->{g} Text) -> Record5 ->{g} Record5、+ Record5.a.set : Text -> Record5 -> Record5）。

值得注意的类型细节（Records.hs 第 34-45 行注释）：setter 与 modifier 采用完全泛化（fully general）的类型。若某个类型变量只被该字段单独引用（soleTyvars），则更新该字段可能改变类型，因此这些变量会在结果类型中被重新置换（freshen）。例如：

-- 对于 type These a b = { here : a, there : b } These.here.set : c -> These a b -> These c b These.here.modify : (a -> c) -> These a b -> These c b

而被多个字段共享（或无字段引用）的类型变量保持固定，得到常规的非类型改变访问器。

访问器的类型检查发生在hashFieldAccessors中：先用Typechecker.synthesize综合类型、再以Type.cleanup归一化（Dependencies.hs 第 118-125 行），若字段存在高阶类型（higher-rank）导致无法推断，hashFieldAccessors返回Nothing（第 75-78 行注释），Record 识别随之失败——这是「Record 无法被识别」的又一来源。

四、尾逗号语法与:added-by-ucm输出解读

文档「Syntax」一节验证了尾逗号（trailing comma）合法：

unique type Record5 = { a : Text, b : Int, }

对应的:added-by-ucm输出块展示了 UCM 对本次改动生成的消息：

Loading changes detected in scratch.u. ~ type Record5 + Record5.a : Record5 -> Text + Record5.a.modify : (Text ->{g} Text) -> Record5 ->{g} Record5 + Record5.a.set : Text -> Record5 -> Record5 + Record5.b : Record5 -> Int + Record5.b.modify : (Int ->{g} Int) -> Record5 ->{g} Record5 + Record5.b.set : Int -> Record5 -> Record5 + (added), ~ (modified) Run `update` to apply these changes to your codebase.

两点解读：

1. :added-by-ucm标记：这是转录框架中表示「该输出由 UCM 自动生成、而非脚本作者手写」的特殊标记，解析逻辑位于 Parser.hs（第 214-218 行），由formatGenerated/generated处理，保证转录结果的输出能自动同步到.output.md。
2. 类型改变型访问器：输出中Record5.a.modify : (Text ->{g} Text) -> Record5 ->{g} Record5中的{g}表示该函数可以携带能力（ability）效果g，说明访问器类型允许纯函数与带效果函数两种形态——这正是 3.3 节「fully general 类型」在语法层面的体现。

另外，尾逗号在解析器层面得到保证：DeclParser.hs中字段分隔逗号为optional，最后一个字段后的逗号不会引发解析错误（见 3.1 节）。

五、如何亲自运行这组测试

records.md属于幂等转录测试（idempotent），这类用例不产生手写输出，而是由框架自动比对多次运行结果是否一致。参照仓库的转录运行方式，在项目根目录执行转录脚本即可，例如通过scripts目录中的转录相关脚本（如 transcripts.sh）或在已构建 UCM 的环境中对unison-src/transcripts/idempotent/records.md运行转录命令。运行后会在同目录生成/比对records.output.md（当前仓库中该用例尚未生成.output.md，属于「预期输出由运行自动生成」的类型，与同目录下如branch-diff.output.md等已固化输出的用例形成对比）。

注意两点：

• 转录脚本要求本地已构建 UCM 可执行文件，且依赖builtins.merge提供的内建类型环境；
• 由于 2.5 节所述 Bug 的存在，RecordWithUserType用例的当前行为（打印仍保留{ ... }形态）即被固化为预期，若未来修复该 Bug，需要同步更新转录期望输出。

六、总结

从records.md这组幂等转录测试可以得到三条结论：

1. 语法保真：字段数从 1 到 20 的 Record，在「声明 →add→view」往返后均能保持{ 字段 : 类型 }语法不变，字段顺序与嵌套类型被完整保留；但换行风格会被打印机统一为「每字段一行 + 尾逗号」的固定格式；
2. 识别机制：打印端通过「单构造器 + 访问器哈希反查名字空间 + 字段名回推」三步判断一个类型是否按 Record 打印，名字缺失或高阶字段导致访问器类型推断失败时，会退化回普通构造器打印——这既是实现细节，也是已知 Bug 的根源；
3. 访问器体系：每个字段自动生成get / set / modify三个访问器，其中 set/modify 的类型可随被唯一引用的类型变量而变化，体现了 Unison Record 语法与类型系统深度耦合的设计。

对于希望为 Unison 语言贡献或排查 Record 相关问题的开发者，可以重点关注 DeclParser.hs、DeclPrinter.hs、Records.hs 与 Dependencies.hs 四个文件，它们构成了 Record 语法「解析 — 入库 — 打印」的完整闭环。

• 编程语言
• 编译器
• 语言运行时
• 开发工具