拓冰网站定制 
Roc 编译器中的值泛化机制深入解读 generalize_annotated_value_block_local 快照测试【免费下载链接】rocA fast, friendly, functional language.项目地址: https://gitcode.com/GitHub_Trending/ro/roc导读本文以 Roc 语言编译器仓库中的快照测试 generalize_annotated_value_block_local.md 为核心深入剖析 Roc 类型系统在 Hindley-Milner 框架下的**值泛化generalization**机制为什么一个带有显式类型注解、位于块block内部而非顶层的非扩张性non-expansive值绑定依然能成为一个真正的多态类型方案scheme并在两个不同的具体类型上实例化。读完本文你将理解 Roc 编译器泛化算法的 rank 分级思想、rigid 变量与 tier-2 泛化的区别、快照测试的验证方法以及如何在 src/types/generalize.zig 等源码中验证这些行为。一、快照测试是什么Roc 编译管道的行为标尺1.1 快照文件的通用结构本仓库使用 test/snapshots/README.md 中描述的机制来固化编译器行为每个快照文件记录一段 Roc 源码SOURCE并固化它在编译管道各阶段的输出——词法分析TOKENS、语法分析PARSE、格式化FORMATTED、规范化CANONICALIZE、类型推断TYPES以及诊断报告PROBLEMS。本关联文档generalize_annotated_value_block_local.md的META部分声明descriptionAn annotated, non-expansive value bound inside a block (not top-level) is still a true scheme, instantiable at two different concrete types (tier-2 generalization) typefile即一个位于块内非顶层、带注解的非扩张性值绑定依然是一个真正的多态 scheme可以在两个不同的具体类型上实例化tier-2 泛化。该文件的EXPECTED与PROBLEMS均为NIL表示这段代码应当无错误、无警告地通过全部编译阶段这正是泛化行为正确的语义断言。1.2 快照的维护方式按照 test/snapshots/README.md 的说明所有快照可通过以下命令生成或更新# 生成全部快照 zig build run-snapshot-tool # 仅更新指定快照 zig build run-snapshot-tool -- test/snapshots/generalize_annotated_value_block_local.md # 用当前诊断结果覆盖 EXPECTED 部分--update-expected zig build run-snapshot-tool -- test/snapshots/generalize_annotated_value_block_local.md --update-expected当编译器行为发生意外变化时快照会立刻在 diff 中暴露出来起到回归检测的作用详见 test/snapshots/README.md。typefile类型的普通快照只固化诊断的语义S-expression 序列化见src/reporting/report_sexpr.zig不含终端渲染细节NIL表示编译未产生任何报告。二、被测代码块内带注解的多态值2.1 源码逐行解读本快照的SOURCE是一段完整的 Roc 程序app [main!] { pf: platform ../basic-cli/main.roc } main! |_| { empty : List(a) empty [] nums : List(U64) nums empty strs : List(Str) strs empty _ nums _ strs {} }逐行拆解这段代码的语义应用头app [main!] { pf: platform ../basic-cli/main.roc }声明这是一个可执行应用暴露入口main!并通过pf字段引用仓库中的基础 CLI 平台../basic-cli/main.roc。关键的第一组绑定位于main!的 lambda 体块内empty : List(a)是显式类型注解a是一个未量化的类型变量ty-varempty []是**非扩张性non-expansive**的右值——空列表字面量不包含任何函数调用、case 分支等扩张性表达式属于最弱的一类值。第二组绑定nums : List(U64); nums empty把empty在U64元素类型上实例化。第三组绑定strs : List(Str); strs empty把empty在Str元素类型上实例化。收尾_ nums; _ strs是为了避免定义了未使用的告警{}是空记录作为main!的返回值。这段代码能在两个不同具体类型List(U64)与List(Str)上复用同一个empty且PROBLEMS为NIL本身就是泛化成功的运行证据——如果empty没有被泛化为真正的多态 scheme第二次以List(Str)使用它就会与第一次实例化产生的List(U64)产生类型冲突。2.2 与顶层版本的对照值得对比的是快照家族中的顶层版本 generalize_annotated_value_multi_type.md它把同样的empty : List(a); empty []放在顶层同样能在List(U64)与List(Str)两个类型上实例化description 标注为 tier-2 generalization。而本关联文档则验证了更强的结论同样的泛化能力在块block内部依然成立块作用域并不会削弱带注解绑定的多态性。这是tier-2 泛化区别于其他泛化层级的关键证据。三、背后的类型系统Hindley-Milner 泛化与 rank3.1 泛化的本质per-variable而非 per-typeRoc 的类型推断基于 Hindley-Milner 系统其核心在于泛化是逐个变量进行的而不是逐个类型进行的见 src/types/generalize.zig。一个类型可以被部分泛化某些变量被量化为多态另一些变量则保持为从外层作用域逃逸出来的共享合一变量shared unification variable。src/types/generalize.zig 的模块注释对 rank 体系给出了精确定义Rank名称含义0generalized已被泛化的多态类型变量泛化后1outermost最外层顶层定义中、因值限制value restriction而未泛化的变量2top_level在最外层 let 绑定处引入的变量3—在嵌套 let 绑定中引入的变量该枚举定义在 src/types/types.ziggeneralized 0、outermost 1其余层级按_递增并配有min/max/next/prev辅助函数src/types/types.zig。注释还说明导入的变量获得 rank 2rank 0 专门留给泛化generic变量src/types/types.zig。核心不变量在一次泛化中被泛化类型里所有变量的 rank 在调整后都满足rank NN 为当前泛化层级。rank 等于 N 的变量会被泛化rank 小于 N 的变量已经逃逸到外层作用域保持单态、与其他引用共享同一变量src/types/generalize.zig。这个不变量正是判断一个变量能否安全量化的依据。3.2 两分类可泛化变量与逃逸变量src/types/generalize.zig 把变量分为两类可泛化变量rank 当前泛化层级在当前作用域引入泛化时被量化每次调用点都会用全新变量实例化逃逸变量rank 当前泛化层级在更外层引入不量化保持为共享合一变量所有引用共享同一变量——这正是值限制value restriction机制的来源。模块注释中的经典示例src/types/generalize.zig说明了部分泛化x 10 # x : αrank 1因值限制未泛化 process |y, _z| { # rank 2 [x, y] # 将 α 与 y 的类型合一 }泛化process时y与来自x的α合一后被拉到 rank 1_z停留在 rank 2。结果是process : ∀β. (α, β) - List(α)——只有_z即β被泛化α与x共享。因此process(1.U8, hello)会把x约束为U8后续调用必须尊重该约束。四、泛化算法流程generalize() 的四步src/types/generalize.zig 中的Generalizer.generalize()是泛化的主入口算法分为四步拷贝到临时池把当前 rank 的所有变量解析resolveVar处理 redirect后移入tmp_var_pool保留各自 rank已泛化的变量不重复处理src/types/generalize.zig。调整 rank从低到高处理每个变量通过adjustRank基于其引用的变量 rank 做调整。被外层变量合一的变量其 rank 会被降低src/types/generalize.zig。区分逃逸与可泛化调整后原本在rank_to_generalize的变量要么 rank 降低逃逸移回主池对应 rank 层要么保持不变可安全泛化置为Rank.generalized。注释特别指出rank 高于当前泛化层级的情况绝不应出现否则说明 reducer 破坏了不变量src/types/generalize.zig。清空主池对应层级src/types/generalize.zig。值得关注的是adjustRank的显式堆栈工作清单worklist设计rank 调整遍历由rank_frames/pending_ranks两个堆上的缓冲驱动而不是原生递归src/types/generalize.zig。单元测试 src/types/generalize.zig 专门构造了一条40000 层深的元组链来验证在普通 8 MiB 原生栈下递归版本会 segfault而堆上工作清单版本可以无栈深限制地完成调整——这是泛化器在大类型上鲁棒性的直接证据。五、从 PARSE 到 CANONICALIZE本快照的管道证据5.1 语法层s-type-anno与ty-var快照的PARSE段展示了注解如何进入语法树。以empty为例(s-type-anno (name empty) (ty-apply (ty (name List)) (ty-var (raw a))))a被解析为类型变量ty-var而List(U64)中的U64则是具名类型应用ty-applyty。main!的整体结构是e-lambda包裹e-block块内依次是类型注解、声明、引用、通配符丢弃和尾表达式e-record。5.2 规范化层注解上升为 annotation 约束CANONICALIZE段展示规范化后的中间表示canonical IR。注意块内绑定empty变成了(s-let (p-assign (ident empty)) (e-empty_list))在规范化 IR 中类型注解s-type-anno从语句流中消失被转换为后续类型检查阶段使用的annotation 元数据对比顶层版本 generalize_annotated_value_multi_type.md 的CANONICALIZE段中(annotation (ty-apply (name List) (builtin) (ty-rigid-var (name a))))可见全貌empty的注解变量a在规范化后对应刚性类型变量rigid varty-rigid-var而nums/strs的注解则引用内置类型查找(ty-lookup (name U64) (builtin))、(ty-lookup (name Str) (builtin))。块内nums empty、strs empty变为e-lookup-local即对局部变量empty的引用。5.3 类型推断结果TYPES段的最终裁决TYPES段是整个测试的结论页(inferred-types (defs (patt (type _arg - {}))) (expressions (expr (type _arg - {}))))只有main!本身_arg - {}被显式列出而块内的empty、nums、strs均未出现在推断类型输出中——这本身不意味着泛化失败因为EXPECTED/PROBLEMS均为NIL编译完全通过。真正的证据链在于如果empty没有被泛化成真正的 scheme那么nums emptyList(U64)与strs emptyList(Str)这两次实例化必然冲突而快照显示它们相安无事——两次引用分别以不同的具体类型实例化了同一个多态绑定。这正是 description 中 a true scheme, instantiable at two different concrete types 的精确含义。六、tier-2 泛化注解即选择加入的开关6.1 扩张性expansiveness与注解的关系本快照标题中的 tier-2 generalization 指第二级泛化其核心规则是显式类型注解本身就是泛化的opt-in。对照快照家族可以看清这一点generalize_annotated_value_expansive.mdmade : List(a); made identity([])——右值是扩张性的包含函数调用identity([])但由于带了注解扩张性并不会阻断泛化made依然可以在List(U64)和List(Str)两个类型上使用。其CANONICALIZE段可见made的注解含ty-rigid-var (name a)同时identity的定义被规范化为(ty-fn (effectful false) (ty-rigid-var (name a)) (ty-rigid-var-lookup ...))——即一个带刚性类型变量注解的函数类型。generalize_annotated_value_unannotated_not_generalized.md反过来不带注解的绑定不会被泛化。也就是说扩张性只会在无注解时通过值限制阻挡泛化一旦提供了注解无论 RHS 是否扩张绑定都会升级为真正的多态 scheme。本关联文档验证的是这条规则中非扩张性 块内 有注解这一组合与顶层版本的差异仅在于绑定出现的层级。6.2 刚性变量在实例化阶段的行为注解中的a在规范化后是刚性变量rigid var。刚性变量在实例化时的行为由 src/types/test/test_rigid_instantiation.zig 中的一组测试固化instantiate - generalized rigid var with fresh_rigid creates new rigid vartest_rigid_instantiation.zig被泛化rank 0的刚性变量以fresh_rigid行为实例化时会生成新的刚性变量且保持刚性instantiate - generalized flex var creates new flex vartest_rigid_instantiation.zig与 instantiate - non-generalized flex var DOES NOT create new flex vartest_rigid_instantiation.zig对照说明只有被泛化的变量才会在每次实例化时得到新副本未泛化的变量保持原样instantiate - func with some generalized and some not preserve non-generalizedtest_rigid_instantiation.zig验证了部分泛化的场景函数类型中未泛化的变量在实例化后仍是同一个变量。这正解释了empty的两次使用a被泛化后每次实例化都产生新鲜的刚性变量分别与U64、Str合一互不干扰。若a未被泛化逃逸为共享变量第一次与U64合一后第二次List(Str)的使用必然报类型错误——而快照显示没有错误反向证明了泛化成功。七、泛化相关的其余快照与扩展阅读围绕同一主题test/snapshots 目录下还有一整套generalize_*快照覆盖泛化机制的各个维度可作为深入学习的对照实验快照文件验证点generalize_annotated_value_block_local.md本文主题块内、非扩张、带注解 → 真 scheme双类型实例化generalize_annotated_value_multi_type.md顶层、非扩张、带注解 → tier-2 泛化generalize_annotated_value_expansive.md扩张性 RHS 注解 → 注解是 opt-in扩张不阻断泛化generalize_annotated_value_nested_expansive.md嵌套扩张性场景generalize_annotated_value_constrained.md带约束的注解值泛化generalize_annotated_value_unannotated_not_generalized.md无注解绑定不被泛化值限制generalize_annotated_value_tag_widening.md标签联合tag union上的泛化行为generalize_annotated_value_record_function_field.md记录函数字段的泛化generalize_alias_chain.md、generalize_alias_in_record.md、generalize_alias_in_tuple.md 等别名alias类型在各类上下文中的泛化核心实现集中在src/types/generalize.zigGeneralizer、adjustRank、VarPool泛化算法主战场src/types/types.zigRank枚举与层级操作src/types/instantiate.zig泛化后的类型在调用点的实例化src/types/test/test_rigid_instantiation.zig刚性/柔性变量实例化行为的单元测试src/check/unify.zig合一过程负责引入变量与 rank 分配。八、小结从快照读懂 Roc 的泛化设计回到本关联文档的META描述可以总结出 Roc 泛化机制的完整设计意图作用域无关性泛化能力不依赖绑定出现在顶层还是块内本快照证明块内同样成立注解即声明显式类型注解是泛化的 opt-in 机制tier-2 泛化下即使 RHS 扩张如函数调用也能泛化变量级粒度泛化逐变量进行通过 rank 区分可量化与已逃逸实现部分泛化与值限制的共存真多态复用泛化后的绑定是真正的 scheme每次引用实例化为独立的新变量从而能在List(U64)与List(Str)等不同具体类型上安全复用。快照测试的价值在于它把这段代码应当无错误地编译这一语义断言连同从词法到类型推断的全管道输出固化在版本库中test/snapshots/README.md。任何泛化算法的改动只要破坏了empty的块内双类型实例化能力都会在此快照的 diff 中原形毕露——这正是编译器工程中用行为标尺守护类型系统的典型实践。【免费下载链接】rocA fast, friendly, functional language.项目地址: https://gitcode.com/GitHub_Trending/ro/roc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Roc 编译器中的值泛化机制：深入解读 generalize_annotated_value_block_local 快照测试
Roc 编译器中的值泛化机制深入解读 generalize_annotated_value_block_local 快照测试【免费下载链接】rocA fast, friendly, functional language.项目地址: https://gitcode.com/GitHub_Trending/ro/roc导读本文以 Roc 语言编译器仓库中的快照测试 generalize_annotated_value_block_local.md 为核心深入剖析 Roc 类型系统在 Hindley-Milner 框架下的**值泛化generalization**机制为什么一个带有显式类型注解、位于块block内部而非顶层的非扩张性non-expansive值绑定依然能成为一个真正的多态类型方案scheme并在两个不同的具体类型上实例化。读完本文你将理解 Roc 编译器泛化算法的 rank 分级思想、rigid 变量与 tier-2 泛化的区别、快照测试的验证方法以及如何在 src/types/generalize.zig 等源码中验证这些行为。一、快照测试是什么Roc 编译管道的行为标尺1.1 快照文件的通用结构本仓库使用 test/snapshots/README.md 中描述的机制来固化编译器行为每个快照文件记录一段 Roc 源码SOURCE并固化它在编译管道各阶段的输出——词法分析TOKENS、语法分析PARSE、格式化FORMATTED、规范化CANONICALIZE、类型推断TYPES以及诊断报告PROBLEMS。本关联文档generalize_annotated_value_block_local.md的META部分声明descriptionAn annotated, non-expansive value bound inside a block (not top-level) is still a true scheme, instantiable at two different concrete types (tier-2 generalization) typefile即一个位于块内非顶层、带注解的非扩张性值绑定依然是一个真正的多态 scheme可以在两个不同的具体类型上实例化tier-2 泛化。该文件的EXPECTED与PROBLEMS均为NIL表示这段代码应当无错误、无警告地通过全部编译阶段这正是泛化行为正确的语义断言。1.2 快照的维护方式按照 test/snapshots/README.md 的说明所有快照可通过以下命令生成或更新# 生成全部快照 zig build run-snapshot-tool # 仅更新指定快照 zig build run-snapshot-tool -- test/snapshots/generalize_annotated_value_block_local.md # 用当前诊断结果覆盖 EXPECTED 部分--update-expected zig build run-snapshot-tool -- test/snapshots/generalize_annotated_value_block_local.md --update-expected当编译器行为发生意外变化时快照会立刻在 diff 中暴露出来起到回归检测的作用详见 test/snapshots/README.md。typefile类型的普通快照只固化诊断的语义S-expression 序列化见src/reporting/report_sexpr.zig不含终端渲染细节NIL表示编译未产生任何报告。二、被测代码块内带注解的多态值2.1 源码逐行解读本快照的SOURCE是一段完整的 Roc 程序app [main!] { pf: platform ../basic-cli/main.roc } main! |_| { empty : List(a) empty [] nums : List(U64) nums empty strs : List(Str) strs empty _ nums _ strs {} }逐行拆解这段代码的语义应用头app [main!] { pf: platform ../basic-cli/main.roc }声明这是一个可执行应用暴露入口main!并通过pf字段引用仓库中的基础 CLI 平台../basic-cli/main.roc。关键的第一组绑定位于main!的 lambda 体块内empty : List(a)是显式类型注解a是一个未量化的类型变量ty-varempty []是**非扩张性non-expansive**的右值——空列表字面量不包含任何函数调用、case 分支等扩张性表达式属于最弱的一类值。第二组绑定nums : List(U64); nums empty把empty在U64元素类型上实例化。第三组绑定strs : List(Str); strs empty把empty在Str元素类型上实例化。收尾_ nums; _ strs是为了避免定义了未使用的告警{}是空记录作为main!的返回值。这段代码能在两个不同具体类型List(U64)与List(Str)上复用同一个empty且PROBLEMS为NIL本身就是泛化成功的运行证据——如果empty没有被泛化为真正的多态 scheme第二次以List(Str)使用它就会与第一次实例化产生的List(U64)产生类型冲突。2.2 与顶层版本的对照值得对比的是快照家族中的顶层版本 generalize_annotated_value_multi_type.md它把同样的empty : List(a); empty []放在顶层同样能在List(U64)与List(Str)两个类型上实例化description 标注为 tier-2 generalization。而本关联文档则验证了更强的结论同样的泛化能力在块block内部依然成立块作用域并不会削弱带注解绑定的多态性。这是tier-2 泛化区别于其他泛化层级的关键证据。三、背后的类型系统Hindley-Milner 泛化与 rank3.1 泛化的本质per-variable而非 per-typeRoc 的类型推断基于 Hindley-Milner 系统其核心在于泛化是逐个变量进行的而不是逐个类型进行的见 src/types/generalize.zig。一个类型可以被部分泛化某些变量被量化为多态另一些变量则保持为从外层作用域逃逸出来的共享合一变量shared unification variable。src/types/generalize.zig 的模块注释对 rank 体系给出了精确定义Rank名称含义0generalized已被泛化的多态类型变量泛化后1outermost最外层顶层定义中、因值限制value restriction而未泛化的变量2top_level在最外层 let 绑定处引入的变量3—在嵌套 let 绑定中引入的变量该枚举定义在 src/types/types.ziggeneralized 0、outermost 1其余层级按_递增并配有min/max/next/prev辅助函数src/types/types.zig。注释还说明导入的变量获得 rank 2rank 0 专门留给泛化generic变量src/types/types.zig。核心不变量在一次泛化中被泛化类型里所有变量的 rank 在调整后都满足rank NN 为当前泛化层级。rank 等于 N 的变量会被泛化rank 小于 N 的变量已经逃逸到外层作用域保持单态、与其他引用共享同一变量src/types/generalize.zig。这个不变量正是判断一个变量能否安全量化的依据。3.2 两分类可泛化变量与逃逸变量src/types/generalize.zig 把变量分为两类可泛化变量rank 当前泛化层级在当前作用域引入泛化时被量化每次调用点都会用全新变量实例化逃逸变量rank 当前泛化层级在更外层引入不量化保持为共享合一变量所有引用共享同一变量——这正是值限制value restriction机制的来源。模块注释中的经典示例src/types/generalize.zig说明了部分泛化x 10 # x : αrank 1因值限制未泛化 process |y, _z| { # rank 2 [x, y] # 将 α 与 y 的类型合一 }泛化process时y与来自x的α合一后被拉到 rank 1_z停留在 rank 2。结果是process : ∀β. (α, β) - List(α)——只有_z即β被泛化α与x共享。因此process(1.U8, hello)会把x约束为U8后续调用必须尊重该约束。四、泛化算法流程generalize() 的四步src/types/generalize.zig 中的Generalizer.generalize()是泛化的主入口算法分为四步拷贝到临时池把当前 rank 的所有变量解析resolveVar处理 redirect后移入tmp_var_pool保留各自 rank已泛化的变量不重复处理src/types/generalize.zig。调整 rank从低到高处理每个变量通过adjustRank基于其引用的变量 rank 做调整。被外层变量合一的变量其 rank 会被降低src/types/generalize.zig。区分逃逸与可泛化调整后原本在rank_to_generalize的变量要么 rank 降低逃逸移回主池对应 rank 层要么保持不变可安全泛化置为Rank.generalized。注释特别指出rank 高于当前泛化层级的情况绝不应出现否则说明 reducer 破坏了不变量src/types/generalize.zig。清空主池对应层级src/types/generalize.zig。值得关注的是adjustRank的显式堆栈工作清单worklist设计rank 调整遍历由rank_frames/pending_ranks两个堆上的缓冲驱动而不是原生递归src/types/generalize.zig。单元测试 src/types/generalize.zig 专门构造了一条40000 层深的元组链来验证在普通 8 MiB 原生栈下递归版本会 segfault而堆上工作清单版本可以无栈深限制地完成调整——这是泛化器在大类型上鲁棒性的直接证据。五、从 PARSE 到 CANONICALIZE本快照的管道证据5.1 语法层s-type-anno与ty-var快照的PARSE段展示了注解如何进入语法树。以empty为例(s-type-anno (name empty) (ty-apply (ty (name List)) (ty-var (raw a))))a被解析为类型变量ty-var而List(U64)中的U64则是具名类型应用ty-applyty。main!的整体结构是e-lambda包裹e-block块内依次是类型注解、声明、引用、通配符丢弃和尾表达式e-record。5.2 规范化层注解上升为 annotation 约束CANONICALIZE段展示规范化后的中间表示canonical IR。注意块内绑定empty变成了(s-let (p-assign (ident empty)) (e-empty_list))在规范化 IR 中类型注解s-type-anno从语句流中消失被转换为后续类型检查阶段使用的annotation 元数据对比顶层版本 generalize_annotated_value_multi_type.md 的CANONICALIZE段中(annotation (ty-apply (name List) (builtin) (ty-rigid-var (name a))))可见全貌empty的注解变量a在规范化后对应刚性类型变量rigid varty-rigid-var而nums/strs的注解则引用内置类型查找(ty-lookup (name U64) (builtin))、(ty-lookup (name Str) (builtin))。块内nums empty、strs empty变为e-lookup-local即对局部变量empty的引用。5.3 类型推断结果TYPES段的最终裁决TYPES段是整个测试的结论页(inferred-types (defs (patt (type _arg - {}))) (expressions (expr (type _arg - {}))))只有main!本身_arg - {}被显式列出而块内的empty、nums、strs均未出现在推断类型输出中——这本身不意味着泛化失败因为EXPECTED/PROBLEMS均为NIL编译完全通过。真正的证据链在于如果empty没有被泛化成真正的 scheme那么nums emptyList(U64)与strs emptyList(Str)这两次实例化必然冲突而快照显示它们相安无事——两次引用分别以不同的具体类型实例化了同一个多态绑定。这正是 description 中 a true scheme, instantiable at two different concrete types 的精确含义。六、tier-2 泛化注解即选择加入的开关6.1 扩张性expansiveness与注解的关系本快照标题中的 tier-2 generalization 指第二级泛化其核心规则是显式类型注解本身就是泛化的opt-in。对照快照家族可以看清这一点generalize_annotated_value_expansive.mdmade : List(a); made identity([])——右值是扩张性的包含函数调用identity([])但由于带了注解扩张性并不会阻断泛化made依然可以在List(U64)和List(Str)两个类型上使用。其CANONICALIZE段可见made的注解含ty-rigid-var (name a)同时identity的定义被规范化为(ty-fn (effectful false) (ty-rigid-var (name a)) (ty-rigid-var-lookup ...))——即一个带刚性类型变量注解的函数类型。generalize_annotated_value_unannotated_not_generalized.md反过来不带注解的绑定不会被泛化。也就是说扩张性只会在无注解时通过值限制阻挡泛化一旦提供了注解无论 RHS 是否扩张绑定都会升级为真正的多态 scheme。本关联文档验证的是这条规则中非扩张性 块内 有注解这一组合与顶层版本的差异仅在于绑定出现的层级。6.2 刚性变量在实例化阶段的行为注解中的a在规范化后是刚性变量rigid var。刚性变量在实例化时的行为由 src/types/test/test_rigid_instantiation.zig 中的一组测试固化instantiate - generalized rigid var with fresh_rigid creates new rigid vartest_rigid_instantiation.zig被泛化rank 0的刚性变量以fresh_rigid行为实例化时会生成新的刚性变量且保持刚性instantiate - generalized flex var creates new flex vartest_rigid_instantiation.zig与 instantiate - non-generalized flex var DOES NOT create new flex vartest_rigid_instantiation.zig对照说明只有被泛化的变量才会在每次实例化时得到新副本未泛化的变量保持原样instantiate - func with some generalized and some not preserve non-generalizedtest_rigid_instantiation.zig验证了部分泛化的场景函数类型中未泛化的变量在实例化后仍是同一个变量。这正解释了empty的两次使用a被泛化后每次实例化都产生新鲜的刚性变量分别与U64、Str合一互不干扰。若a未被泛化逃逸为共享变量第一次与U64合一后第二次List(Str)的使用必然报类型错误——而快照显示没有错误反向证明了泛化成功。七、泛化相关的其余快照与扩展阅读围绕同一主题test/snapshots 目录下还有一整套generalize_*快照覆盖泛化机制的各个维度可作为深入学习的对照实验快照文件验证点generalize_annotated_value_block_local.md本文主题块内、非扩张、带注解 → 真 scheme双类型实例化generalize_annotated_value_multi_type.md顶层、非扩张、带注解 → tier-2 泛化generalize_annotated_value_expansive.md扩张性 RHS 注解 → 注解是 opt-in扩张不阻断泛化generalize_annotated_value_nested_expansive.md嵌套扩张性场景generalize_annotated_value_constrained.md带约束的注解值泛化generalize_annotated_value_unannotated_not_generalized.md无注解绑定不被泛化值限制generalize_annotated_value_tag_widening.md标签联合tag union上的泛化行为generalize_annotated_value_record_function_field.md记录函数字段的泛化generalize_alias_chain.md、generalize_alias_in_record.md、generalize_alias_in_tuple.md 等别名alias类型在各类上下文中的泛化核心实现集中在src/types/generalize.zigGeneralizer、adjustRank、VarPool泛化算法主战场src/types/types.zigRank枚举与层级操作src/types/instantiate.zig泛化后的类型在调用点的实例化src/types/test/test_rigid_instantiation.zig刚性/柔性变量实例化行为的单元测试src/check/unify.zig合一过程负责引入变量与 rank 分配。八、小结从快照读懂 Roc 的泛化设计回到本关联文档的META描述可以总结出 Roc 泛化机制的完整设计意图作用域无关性泛化能力不依赖绑定出现在顶层还是块内本快照证明块内同样成立注解即声明显式类型注解是泛化的 opt-in 机制tier-2 泛化下即使 RHS 扩张如函数调用也能泛化变量级粒度泛化逐变量进行通过 rank 区分可量化与已逃逸实现部分泛化与值限制的共存真多态复用泛化后的绑定是真正的 scheme每次引用实例化为独立的新变量从而能在List(U64)与List(Str)等不同具体类型上安全复用。快照测试的价值在于它把这段代码应当无错误地编译这一语义断言连同从词法到类型推断的全管道输出固化在版本库中test/snapshots/README.md。任何泛化算法的改动只要破坏了empty的块内双类型实例化能力都会在此快照的 diff 中原形毕露——这正是编译器工程中用行为标尺守护类型系统的典型实践。【免费下载链接】rocA fast, friendly, functional language.项目地址: https://gitcode.com/GitHub_Trending/ro/roc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考