Roc 语言 match 表达式中的列表下划线模式：从快照测试看通配符、rest 与解构语义

Roc 语言 match 表达式中的列表下划线模式从快照测试看通配符、rest 与解构语义【免费下载链接】rocA fast, friendly, functional language.项目地址: https://gitcode.com/GitHub_Trending/ro/roc在 Roc 语言中match表达式配合列表模式list pattern可以对任意长度的列表进行结构化匹配而下划线_作为不绑定任何名字的通配符让你能精确定位第几个元素而忽略其余部分。本文以仓库快照测试 list_underscore_patterns.md 为骨架完整拆解[_]、[first, ..]、[.., last]、[_, _, third]、[x, _, _, y]、[]六种模式的写法、匹配语义与求值结果并结合 Pattern.zig 源码与快照测试机制见 test/snapshots/README.md讲清它们从词法、解析、格式化到规范化的完整编译流水线。读完你将掌握 Roc 列表解构的实战写法并理解如何阅读与运行编译器快照测试来验证这些行为。关联文档是什么一份编译器快照测试test/snapshots/match_expr/list_underscore_patterns.md不是普通的手册文档而是一份快照测试snapshot test。Roc 编译器团队用这类文件拍摄一段 Roc 源码经过每个编译阶段后的输出用来锁定行为、防止回归。仓库的 test/snapshots/README.md 明确说明快照测试通过展示源码如何被依次转换为 tokenization、parsing、canonicalization、type checking 等阶段的结果为编译流水线提供全面验证。该文件采用标题 代码块的结构组织各阶段产物META元信息descriptionMatch expression with underscore patterns in list matching、typeexpr按表达式快照运行SOURCE被测的 Roc 源码片段EXPECTED/PROBLEMS预期诊断结果本文件中两者均为NIL表示该源码不产生任何编译错误或警告TOKENS词法分析输出的 token 序列zig 风格枚举列表PARSE解析阶段生成的语法树S-expressionFORMATTED格式化器输出含规范化注释的版本CANONICALIZE规范化阶段输出的中间表示TYPES整个表达式的推断类型。因此这份文档既是一份语法教学素材也是编译器的行为契约。你可以通过zig build run-snapshot-tool亲自复现详见下文如何运行快照测试一节。核心语法下划线模式与列表模式的六种组合快照的SOURCE节展示了一个完整的match items表达式其被匹配对象是items类型为Dec即十进制数列表见TYPES节的(expr (type Dec))。六个分支分别演示了列表模式下_与具名标识符、rest 模式..的不同组合match items { [_] 1 # pattern match on a list with a single (ignored) element [.., last] last # pattern match on the last item in the list [first, ..] first # pattern match on the first item in the list [_, _, third] third # pattern match on the third item in the list [x, _, _, y] x y # first fourth item in the list [] 0 # match an empty list }逐个解读各分支的语义分支模式匹配条件绑定/忽略分支求值[_]恰好 1 个元素的列表忽略唯一元素1[.., last]至少 1 个元素的列表末尾元素绑定为lastlast[first, ..]至少 1 个元素的列表首元素绑定为firstfirst[_, _, third]恰好 3 个元素的列表忽略前两个第三个绑定为thirdthird[x, _, _, y]恰好 4 个元素的列表首尾分别绑定x、y中间两个忽略x y[]空列表无0这里有几个关键设计点_不引入任何绑定。[_]只关心列表长度是 1而不关心那个元素是什么——它甚至不需要是同一种具体类型参与运算。这在解析树PARSE节中体现为(p-underscore)而具名元素则解析为(p-ident (raw first))等。rest 模式..可以出现在首部或尾部。[.., last]与[first, ..]都是合法写法规范化后分别对应(rest-at (index 0))与(rest-at (index 1))表示 rest 部分在列表中的切分位置详见下文规范化。位置即语义。[_, _, third]中两个_各占一个槽位因此该模式只匹配长度为 3 的列表[x, _, _, y]则精确匹配长度为 4 的列表。_与具名标识符可以任意混排。从 TOKENS 到 PARSE词法与语法层面如何表示快照的TOKENS节给出了这段源码的词法输出KwMatch,LowerIdent,OpenCurly, OpenSquare,Underscore,CloseSquare,OpFatArrow,Int, OpenSquare,DoubleDot,Comma,LowerIdent,CloseSquare,OpFatArrow,LowerIdent, OpenSquare,LowerIdent,Comma,DoubleDot,CloseSquare,OpFatArrow,LowerIdent, OpenSquare,Underscore,Comma,Underscore,Comma,LowerIdent,CloseSquare,OpFatArrow,LowerIdent, OpenSquare,LowerIdent,Comma,Underscore,Comma,Underscore,Comma,LowerIdent,CloseSquare,OpFatArrow,LowerIdent,OpPlus,LowerIdent, OpenSquare,CloseSquare,OpFatArrow,Int, CloseCurly, EndOfFile,可以观察到下划线_是一个独立 tokenUnderscore而不是标识符的一部分列表定界符是OpenSquare/CloseSquare[/]rest 模式由DoubleDot..表示是OpFatArrow是OpPlus行尾EndOfFile表示输入已消费完毕。到了PARSE节语法树完整保留了模式的嵌套结构。以[x, _, _, y] x y分支为例(branch (p-list (p-ident (raw x)) (p-underscore) (p-underscore) (p-ident (raw y))) (e-binop (op ) (e-ident (raw x)) (e-ident (raw y))))解析阶段就把模式pattern与表达式expression清晰分离p-list内的每个槽位是子模式右侧是分支体e-binop。对照源码实现Pattern.zig 中的Patternunion 正是这些p-*构造在编译器内部的数据结构assign表示标识符绑定、as表示重命名、applied_tag表示带载荷的标签构造器、list表示列表解构内含patterns与可选的rest_info。CANONICALIZE下划线如何被规范化为 p-underscore规范化canonicalization是 Roc 编译流水线中把用户友好的语法树转化为语义明确、便于后续类型检查与代码生成的中间表示的一步。快照的CANONICALIZE节展示了_与具名标识符在这个阶段的差异化处理每个_规范化为(p-underscore)例如第一个分支(p-list (patterns (p-underscore)))每个具名元素规范化为(p-assign (ident first))之类的赋值模式供后续以e-lookup-local读取rest 位置被显式记录为(rest-at (index N))[.., last]是(rest-at (index 0))[first, ..]是(rest-at (index 1))空列表[]规范化为空的(p-list (patterns))分支体x y被解析为(e-dispatch-call (method plus) ...)即在 Roc 中是对Num特质的派发调用。一个值得注意的细节整个match的规范化结果在最前面带有一个条件(e-runtime-error (tag ident_not_in_scope))。从源码结构看这是编译器为尚未解析的items快照片段中没有给出其定义预留的运行期错误处理路径——由于本例类型检查最终给出(expr (type Dec))且PROBLEMS为NIL可以推断在真实上下文中items被声明为十进制数列表后该错误路径不会触发。_与具名模式在规范化后的核心差异是p-underscore不产生任何赋值绑定因此不会在作用域中引入名字也不会有未使用变量警告而p-assign会注册绑定若分支体中未使用则触发 warning。这一点可对照 wildcard_patterns.md 中变量捕获全部模式other ...规范化为(p-assign (ident other))来理解两者的边界。FORMATTED格式化器的规范化输出快照的FORMATTED节显示格式化器会统一缩进为 tab、统一分支对齐并移除内联注释match items { [_] 1 # pattern match on a list with a single (ignored) element [.., last] last # pattern match on the last item in the list [first, ..] first # pattern match on the first item in the list [_, _, third] third # pattern match on the third item in the list [x, _, _, y] x y # first fourth item in the list [] 0 }注意#注释仅保留在SOURCE中作为教学说明格式化输出里被剥离且模式与表达式本身未被改写保持语义不变。这印证了格式化器是语法保持syntax-preserving的..的位置、_的个数都原样保留。进阶rest 模式的命名形式与常见陷阱_之外rest 模式本身还有命名形式。快照 list_patterns.md 揭示了一个重要变化旧的[first, ..rest]写法已废弃。该快照的PROBLEMS节包含一条Old List Rest Pattern错误报告提示List rest patterns now use.. as name并给出正确示例[first, .. as rest]。其FORMATTED节将源码自动改写为[first, .. as rest] 0因此当前规范语法为无名 rest[first, ..]忽略剩余元素或[.., last]忽略开头元素具名 rest[first, .. as rest]把剩余元素绑定为rest名字必须放在as之后。在 Pattern.zig 中list模式的rest_info字段记录了 rest 的切分index与可选的绑定这正是..与.. as rest两种形态在中间表示上的落点。相关作用域与合法性边界可继续参考 list_rest_scoping.md、list_rest_invalid.md 与 list_patterns_err_multiple_rest.md 等快照。如何运行这份快照测试要亲手复现本文档的所有阶段输出需要使用 Zig 构建系统运行快照工具详见 test/snapshots/README.md# 更新指定快照文件重新生成各阶段输出 zig build run-snapshot-tool -- test/snapshots/match_expr/list_underscore_patterns.md # 当诊断结果PROBLEMS变化时用期望值更新快照 zig build run-snapshot-tool -- test/snapshots/match_expr/list_underscore_patterns.md --update-expected快照测试的价值在于任何编译阶段的行为变化如 token 命名、解析树结构、规范化表示、格式化输出都会使对应PROBLEMS/TOKENS/PARSE/CANONICALIZE/FORMATTED节产生差异从而暴露回归。由于本文档的EXPECTED与PROBLEMS均为NIL它同时也是一个该写法应当无诊断通过的编译契约_通配、rest 位置、空列表分支的组合都应当被编译器无警告地接受。小结从test/snapshots/match_expr/list_underscore_patterns.md可以提炼出 Roc 列表模式匹配的三条核心结论_是占位即忽略它占据一个元素槽位但绝不绑定名字因此[_]、[_, _, third]、[x, _, _, y]可以精确表达长度固定 部分元素需要的匹配意图rest 模式..可前可后[first, ..]取头、[.., last]取尾需要绑定剩余元素时使用[.. as rest]旧..rest语法已废弃快照测试即文档这份文件完整记录了同一段源码在 tokenization、parsing、格式化、canonicalization、类型推断五个阶段的真实输出是理解编译器内部表示的一手材料也可以用zig build run-snapshot-tool随时复现。若想继续深入可对照阅读 Pattern.zig 了解p-*模式的完整定义浏览 match_expr 目录 下的兄弟快照如 list_patterns.md、wildcard_patterns.md、middle_rest.md对比不同模式的诊断差异以及 docs/langref/pattern-matching.md 中的官方语言参考框架。【免费下载链接】rocA fast, friendly, functional language.项目地址: https://gitcode.com/GitHub_Trending/ro/roc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考