roc 编译器表达式快照测试深度解析从 Token 到类型的 Tuple 表达式全链路【免费下载链接】rocA fast, friendly, functional language.项目地址: https://gitcode.com/GitHub_Trending/ro/roc导读本文以 roc 编译器仓库中的表达式快照测试 test/snapshots/expr/tuple.md 为骨架逐段剖析一个最简单的三元组表达式(1, hello, True)在编译器内部经历的完整处理管线——Token 化、语法解析Parse、格式化校验、规范化Canonicalize与类型推导Types。读者读完将掌握 roc 快照测试文件的结构约定、元组Tuple表达式的 AST 表示方式以及如何通过同类快照文件元组访问、元组模式、元组类型在源码层面验证编译器的行为。快照测试roc 编译器行为的一手“体检报告”在 roc 仓库中test/snapshots/expr/目录存放着大量表达式级别的快照测试文件每个文件对应一个或多个源表达式并用固定分节记录编译器各阶段的输出。文件名即测试主题例如同目录下还有tuple_access_simple.md元组元素访问、tuple_access_chain.md链式访问、tuple_patterns.md元组解构模式、tuple_type.md元组类型标注、tuple_comprehensive.md元组综合用例等共同构成元组特性的完整测试矩阵。快照文件采用“分节”结构节名以#开头、内容用~~~围栏包裹META以 INI 格式记录测试描述与类型本文件的typeexpr表示表达式级测试SOURCE被测的 roc 源码EXPECTED期望的诊断/错误NIL表示无错误PROBLEMS编译器实际产生的诊断NIL表示无问题TOKENS词法分析产出的 Token 序列PARSE语法分析产出的 ASTClojure 形式FORMATTED格式化后的代码NO CHANGE表示已是最优格式CANONICALIZE规范化去语法糖、解析名称后的中间表示TYPES类型推导结果。本文将以 tuple.md 为主线逐节解读每一条记录背后的编译原理。SOURCE被测源码与被测点(1, hello, True)这是 roc 中最典型的“异构元组”一个Dec十进制整数、一个字符串字面量、一个True标签。元组是 roc 内置的数据结构允许把不同类型的值打包在一起按位置访问常用于函数多返回值、成组传参等场景。TOKENS词法阶段看到的结构OpenRound,Int,Comma,StringStart,StringPart,StringEnd,Comma,UpperIdent,CloseRound, EndOfFile,词法分析把源码切分成 9 个有效 Token 加一个文件结束符Token含义OpenRound左圆括号(元组开始Int整数1Comma逗号元组元素分隔符StringStart/StringPart/StringEnd字符串hello的三段式 TokenUpperIdent大写开头的标识符这里是标签TrueCloseRound右圆括号)元组结束EndOfFile文件结束值得注意元组的边界 Token 是OpenRound/CloseRound带空格的普通括号而不是NoSpaceOpenRound。在 roc 的词法约定中NoSpaceOpenRound用于表示紧贴前一个 Token 的调用括号如f(x)而元组括号是独立的成对结构。对比 tuple_access_simple.md 中(a, b).0的 Token 序列可以看到访问运算符对应NoSpaceDotInt这说明“点号 索引”被词法器合成一个 Token 而非拆分两个。PARSE语法分析产出元组 AST(e-tuple (e-int (raw 1)) (e-string (e-string-part (raw hello))) (e-tag (raw True)))PARSE 阶段把 Token 序列构造成 ASTe-tuple节点按顺序挂载三个子表达式——e-int整数、e-string内含e-string-part保存原始文本、e-tag标签。元组的“分组括号”在这里转化为真正的“元组节点”这是 roc 语法中“括号表达式可能是分组也可能是元组”的关键区分点只有包含逗号、或被显式解析为元组的括号表达式才会成为e-tuple。这一阶段与源码中的解析器对应。在 src/parse/Parser.zig 中括号与元组的解析围绕OpenRound、NoSpaceOpenRound、CloseRound展开例如src/parse/Parser.zig中对括号前瞻的判断元组表达式最终通过addExpr(.{ .tuple .{ .items span, ... } })写入 AST 节点存储见src/parse/Parser.zig与 src/parse/NodeStore.zig。也就是说快照中的e-tuple正是AST.Expr的tuple变体在 Clojure 打印形式下的呈现。FORMATTED格式化校验与“稳定格式”保证NO CHANGEFORMATTED 节输出NO CHANGE表示对源码运行 roc 格式化器后结果与输入完全一致。这是快照测试的隐含断言之一(1, hello, True)这种紧凑写法本身已符合 roc 的规范格式不需要重排。对比 tuple_comprehensive.md其中包含空元组()、单元素(42)、二元(1, 2)、三元(1, hello, True)、嵌套((1, 2), (3, 4))、混合(add_one(5), world, [1, 2, 3])、变量元组(x, y, z)与含 lambda 的元组(|n| n 1, 42)其 FORMATTED 节同样保持原样印证 roc 对这些写法均有稳定的格式化输出。CANONICALIZE去语法糖后的规范表示(e-tuple (elems (e-num (value 1)) (e-string (e-literal (string hello))) (e-tag (name True))))CANONICALIZE 是编译器中端的关键步骤它把 PARSE 阶段“面向源码”的 AST 转换成“面向语义”的规范表示e-int (raw 1)→e-num (value 1)原始文本被解析为数值节点从e-int泛化为e-nume-string-part (raw hello)→e-literal (string hello)字符串拼接片段被合并为字面量e-tag (raw True)→e-tag (name True)标签从原始拼写变为按名字引用元组子节点统一放入elems集合语义为“一组元素”。这些变换对应源码中的规范化实现在 src/canonicalize/Can.zig 中e_tuple与e_tuple_access属于表达式分析的分派分支如Can.zig中.e_tuple |tuple|处理元素跨度、.e_tuple_access处理被访问的元组表达式tuple类型的模式也会与表达式按元数、元素数做形状匹配Can.zig中.tuple |pattern_tuple|检查item_patterns.len与expr.tuple.items长度一致。这解释了为什么elems的数量关系在规范化与后续检查中如此重要。顺带一提tuple_comprehensive.md 的 CANONICALIZE 节展示了更有趣的边界空元组empty ()被规范化为e-runtime-error (tag empty_tuple)——即 roc 中空元组没有合法值读取它会成为运行时错误而单元素(42)被规范化为e-num即“只有一个元素时括号仅是分组而非元组”。TYPES类型推导的最终裁决(expr (type (Dec, Str, [True, ..])))类型推导把规范表示解释为类型Dec十进制整数类型对应1Str字符串类型对应hello[True, ..]一个至少包含True标签的开放标签联合类型对应Trueroc 中True/False本身是标签布尔类型是标签联合的语法糖。元组的类型是各元素类型的笛卡尔积式组合(T1, T2, T3)。这一点在 boolean_tuple.md 中得到印证(True, False)的推导结果是([True, ..], [False, ..])——True与False各自保留为开放联合的标签成员。同时该文件 META 节表明这是一个“验证元组中 True/False 解析为 Bool 类型”的专项测试。若元素类型不匹配类型检查器会拒绝程序。tuple_type.md 演示了错误路径函数f : (Str, Str) - (Str, Str)被传入f((1, 2))EXPECTED 与 PROBLEMS 节记录了两条TYPE MISMATCH报告指出“该数字被用于需要非数字类型的位置”并高亮源码第 5 行 8~9、11~12 列两个整数参数的位置期望类型为Str。这是快照测试“负面用例”的价值所在不仅能断言正确程序的输出还能精确断言错误诊断的文本、位置与严重级别。同类快照元组的三种进阶用法围绕 tuple.md 这条主线同目录快照把元组的能力边界补齐1. 元素访问与链式访问(a, b).0tuple_access_simple.md在 PARSE 阶段成为e-tuple-access节点索引保存为字符串.0规范化为e-tuple-access (index 0)推导类型为Str——即访问元组第一个元素得到字符串。((1, 2), (3, 4)).0.1tuple_access_chain.md展示链式访问PARSE 中e-tuple-access嵌套两层规范化后按“先取.0再取.1”的顺序折叠为嵌套节点最终类型为Dec(1, 2).1即整数2。2. 元组模式解构tuple_patterns.md 展示了解构赋值(x, y) (1, 2)的左侧是p-tuple模式规范化为p-tuple (patterns ...)与右侧e-tuple (elems ...)一一对应嵌套模式((a, b), (c, d))、含列表的模式([1, 2, 3], hello)均可成立最终块表达式类型为{}。这与Can.zig中“元组模式与元组表达式按元素数匹配”的实现相互印证。3. 元组类型标注元组不仅可用于表达式还可作为类型标注f : (Str, Str) - (Str, Str)tuple_type.md在 PARSE 阶段生成ty-tuple节点ty内嵌Str表示“接收一个二元字符串元组、返回一个二元字符串元组的函数”。类型标注中的元组与表达式中的元组走同一套长度检查逻辑违规即触发上述类型不匹配诊断。如何在本地复现这些快照这些快照文件由 roc 编译器的测试体系驱动。仓库根目录包含 BUILDING_FROM_SOURCE.md源码构建说明与build.zig快照测试逻辑位于src/check/snapshot/含diff.zig等以及test/snapshots/下的用例集合。在本地按构建文档编译出roc后即可运行测试套件校验快照是否与编译器当前行为一致若编译器行为发生变更快照 diff 会精确指出期望输出与实际输出的差异。要注意的是快照断言与编译器版本强绑定——本文记录的所有 Token、AST、类型输出均以当前仓库快照为准。小结从(1, hello, True)这一个三元组出发test/snapshots/expr/tuple.md 完整呈现了 roc 编译器从词法到类型的六阶段流水线TOKENS的词法切分、PARSE的 AST 构造e-tuple、FORMATTED的格式稳定性、CANONICALIZE的语义归一elems/e-num/e-literal/e-tag、以及TYPES的类型推导(Dec, Str, [True, ..])。配合 tuple_access_simple.md、tuple_access_chain.md、tuple_patterns.md、tuple_type.md 与 tuple_comprehensive.md 等姊妹快照可以拼出 roc 元组特性的完整图谱构建、访问、解构、类型标注、错误诊断与边界情况。快照测试既是编译器行为最忠实的记录者也是理解一门语言内部设计的最直接教材。【免费下载链接】rocA fast, friendly, functional language.项目地址: https://gitcode.com/GitHub_Trending/ro/roc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 roc 编译器表达式快照测试深度解析：从 Token 到类型的 Tuple 表达式全链路
roc 编译器表达式快照测试深度解析从 Token 到类型的 Tuple 表达式全链路【免费下载链接】rocA fast, friendly, functional language.项目地址: https://gitcode.com/GitHub_Trending/ro/roc导读本文以 roc 编译器仓库中的表达式快照测试 test/snapshots/expr/tuple.md 为骨架逐段剖析一个最简单的三元组表达式(1, hello, True)在编译器内部经历的完整处理管线——Token 化、语法解析Parse、格式化校验、规范化Canonicalize与类型推导Types。读者读完将掌握 roc 快照测试文件的结构约定、元组Tuple表达式的 AST 表示方式以及如何通过同类快照文件元组访问、元组模式、元组类型在源码层面验证编译器的行为。快照测试roc 编译器行为的一手“体检报告”在 roc 仓库中test/snapshots/expr/目录存放着大量表达式级别的快照测试文件每个文件对应一个或多个源表达式并用固定分节记录编译器各阶段的输出。文件名即测试主题例如同目录下还有tuple_access_simple.md元组元素访问、tuple_access_chain.md链式访问、tuple_patterns.md元组解构模式、tuple_type.md元组类型标注、tuple_comprehensive.md元组综合用例等共同构成元组特性的完整测试矩阵。快照文件采用“分节”结构节名以#开头、内容用~~~围栏包裹META以 INI 格式记录测试描述与类型本文件的typeexpr表示表达式级测试SOURCE被测的 roc 源码EXPECTED期望的诊断/错误NIL表示无错误PROBLEMS编译器实际产生的诊断NIL表示无问题TOKENS词法分析产出的 Token 序列PARSE语法分析产出的 ASTClojure 形式FORMATTED格式化后的代码NO CHANGE表示已是最优格式CANONICALIZE规范化去语法糖、解析名称后的中间表示TYPES类型推导结果。本文将以 tuple.md 为主线逐节解读每一条记录背后的编译原理。SOURCE被测源码与被测点(1, hello, True)这是 roc 中最典型的“异构元组”一个Dec十进制整数、一个字符串字面量、一个True标签。元组是 roc 内置的数据结构允许把不同类型的值打包在一起按位置访问常用于函数多返回值、成组传参等场景。TOKENS词法阶段看到的结构OpenRound,Int,Comma,StringStart,StringPart,StringEnd,Comma,UpperIdent,CloseRound, EndOfFile,词法分析把源码切分成 9 个有效 Token 加一个文件结束符Token含义OpenRound左圆括号(元组开始Int整数1Comma逗号元组元素分隔符StringStart/StringPart/StringEnd字符串hello的三段式 TokenUpperIdent大写开头的标识符这里是标签TrueCloseRound右圆括号)元组结束EndOfFile文件结束值得注意元组的边界 Token 是OpenRound/CloseRound带空格的普通括号而不是NoSpaceOpenRound。在 roc 的词法约定中NoSpaceOpenRound用于表示紧贴前一个 Token 的调用括号如f(x)而元组括号是独立的成对结构。对比 tuple_access_simple.md 中(a, b).0的 Token 序列可以看到访问运算符对应NoSpaceDotInt这说明“点号 索引”被词法器合成一个 Token 而非拆分两个。PARSE语法分析产出元组 AST(e-tuple (e-int (raw 1)) (e-string (e-string-part (raw hello))) (e-tag (raw True)))PARSE 阶段把 Token 序列构造成 ASTe-tuple节点按顺序挂载三个子表达式——e-int整数、e-string内含e-string-part保存原始文本、e-tag标签。元组的“分组括号”在这里转化为真正的“元组节点”这是 roc 语法中“括号表达式可能是分组也可能是元组”的关键区分点只有包含逗号、或被显式解析为元组的括号表达式才会成为e-tuple。这一阶段与源码中的解析器对应。在 src/parse/Parser.zig 中括号与元组的解析围绕OpenRound、NoSpaceOpenRound、CloseRound展开例如src/parse/Parser.zig中对括号前瞻的判断元组表达式最终通过addExpr(.{ .tuple .{ .items span, ... } })写入 AST 节点存储见src/parse/Parser.zig与 src/parse/NodeStore.zig。也就是说快照中的e-tuple正是AST.Expr的tuple变体在 Clojure 打印形式下的呈现。FORMATTED格式化校验与“稳定格式”保证NO CHANGEFORMATTED 节输出NO CHANGE表示对源码运行 roc 格式化器后结果与输入完全一致。这是快照测试的隐含断言之一(1, hello, True)这种紧凑写法本身已符合 roc 的规范格式不需要重排。对比 tuple_comprehensive.md其中包含空元组()、单元素(42)、二元(1, 2)、三元(1, hello, True)、嵌套((1, 2), (3, 4))、混合(add_one(5), world, [1, 2, 3])、变量元组(x, y, z)与含 lambda 的元组(|n| n 1, 42)其 FORMATTED 节同样保持原样印证 roc 对这些写法均有稳定的格式化输出。CANONICALIZE去语法糖后的规范表示(e-tuple (elems (e-num (value 1)) (e-string (e-literal (string hello))) (e-tag (name True))))CANONICALIZE 是编译器中端的关键步骤它把 PARSE 阶段“面向源码”的 AST 转换成“面向语义”的规范表示e-int (raw 1)→e-num (value 1)原始文本被解析为数值节点从e-int泛化为e-nume-string-part (raw hello)→e-literal (string hello)字符串拼接片段被合并为字面量e-tag (raw True)→e-tag (name True)标签从原始拼写变为按名字引用元组子节点统一放入elems集合语义为“一组元素”。这些变换对应源码中的规范化实现在 src/canonicalize/Can.zig 中e_tuple与e_tuple_access属于表达式分析的分派分支如Can.zig中.e_tuple |tuple|处理元素跨度、.e_tuple_access处理被访问的元组表达式tuple类型的模式也会与表达式按元数、元素数做形状匹配Can.zig中.tuple |pattern_tuple|检查item_patterns.len与expr.tuple.items长度一致。这解释了为什么elems的数量关系在规范化与后续检查中如此重要。顺带一提tuple_comprehensive.md 的 CANONICALIZE 节展示了更有趣的边界空元组empty ()被规范化为e-runtime-error (tag empty_tuple)——即 roc 中空元组没有合法值读取它会成为运行时错误而单元素(42)被规范化为e-num即“只有一个元素时括号仅是分组而非元组”。TYPES类型推导的最终裁决(expr (type (Dec, Str, [True, ..])))类型推导把规范表示解释为类型Dec十进制整数类型对应1Str字符串类型对应hello[True, ..]一个至少包含True标签的开放标签联合类型对应Trueroc 中True/False本身是标签布尔类型是标签联合的语法糖。元组的类型是各元素类型的笛卡尔积式组合(T1, T2, T3)。这一点在 boolean_tuple.md 中得到印证(True, False)的推导结果是([True, ..], [False, ..])——True与False各自保留为开放联合的标签成员。同时该文件 META 节表明这是一个“验证元组中 True/False 解析为 Bool 类型”的专项测试。若元素类型不匹配类型检查器会拒绝程序。tuple_type.md 演示了错误路径函数f : (Str, Str) - (Str, Str)被传入f((1, 2))EXPECTED 与 PROBLEMS 节记录了两条TYPE MISMATCH报告指出“该数字被用于需要非数字类型的位置”并高亮源码第 5 行 8~9、11~12 列两个整数参数的位置期望类型为Str。这是快照测试“负面用例”的价值所在不仅能断言正确程序的输出还能精确断言错误诊断的文本、位置与严重级别。同类快照元组的三种进阶用法围绕 tuple.md 这条主线同目录快照把元组的能力边界补齐1. 元素访问与链式访问(a, b).0tuple_access_simple.md在 PARSE 阶段成为e-tuple-access节点索引保存为字符串.0规范化为e-tuple-access (index 0)推导类型为Str——即访问元组第一个元素得到字符串。((1, 2), (3, 4)).0.1tuple_access_chain.md展示链式访问PARSE 中e-tuple-access嵌套两层规范化后按“先取.0再取.1”的顺序折叠为嵌套节点最终类型为Dec(1, 2).1即整数2。2. 元组模式解构tuple_patterns.md 展示了解构赋值(x, y) (1, 2)的左侧是p-tuple模式规范化为p-tuple (patterns ...)与右侧e-tuple (elems ...)一一对应嵌套模式((a, b), (c, d))、含列表的模式([1, 2, 3], hello)均可成立最终块表达式类型为{}。这与Can.zig中“元组模式与元组表达式按元素数匹配”的实现相互印证。3. 元组类型标注元组不仅可用于表达式还可作为类型标注f : (Str, Str) - (Str, Str)tuple_type.md在 PARSE 阶段生成ty-tuple节点ty内嵌Str表示“接收一个二元字符串元组、返回一个二元字符串元组的函数”。类型标注中的元组与表达式中的元组走同一套长度检查逻辑违规即触发上述类型不匹配诊断。如何在本地复现这些快照这些快照文件由 roc 编译器的测试体系驱动。仓库根目录包含 BUILDING_FROM_SOURCE.md源码构建说明与build.zig快照测试逻辑位于src/check/snapshot/含diff.zig等以及test/snapshots/下的用例集合。在本地按构建文档编译出roc后即可运行测试套件校验快照是否与编译器当前行为一致若编译器行为发生变更快照 diff 会精确指出期望输出与实际输出的差异。要注意的是快照断言与编译器版本强绑定——本文记录的所有 Token、AST、类型输出均以当前仓库快照为准。小结从(1, hello, True)这一个三元组出发test/snapshots/expr/tuple.md 完整呈现了 roc 编译器从词法到类型的六阶段流水线TOKENS的词法切分、PARSE的 AST 构造e-tuple、FORMATTED的格式稳定性、CANONICALIZE的语义归一elems/e-num/e-literal/e-tag、以及TYPES的类型推导(Dec, Str, [True, ..])。配合 tuple_access_simple.md、tuple_access_chain.md、tuple_patterns.md、tuple_type.md 与 tuple_comprehensive.md 等姊妹快照可以拼出 roc 元组特性的完整图谱构建、访问、解构、类型标注、错误诊断与边界情况。快照测试既是编译器行为最忠实的记录者也是理解一门语言内部设计的最直接教材。【免费下载链接】rocA fast, friendly, functional language.项目地址: https://gitcode.com/GitHub_Trending/ro/roc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考