Roc 語言 Dollar 前綴語義全解記錄字段標簽、模式綁定與 var 可變性的邊界【免費下載鏈接】rocA fast, friendly, functional language.項目地址: https://gitcode.com/GitHub_Trending/ro/roc導讀本篇文章基于 Roc 編譯器倉庫roc中的快照測試文件 dollar_prefix_record_fields.md系統(tǒng)講解$Dollar前綴標識符在 Roc 中的完整語義它既可以在記錄字面量與類型標注中作為字段標簽合法存在又會在記錄模式punned pattern中被解釋為一個不可變綁定從而觸發(fā) Dollar Prefix Withoutvar 與 Unused Variable 兩個編譯期警告。讀完本文你將掌握$前綴在 tokenize、parse、canonicalize 與類型推斷各階段的真實行為以及如何在實踐中正確修復相關(guān)警告。原文同時配套 dollar_prefix_field_name.md 與 issue_10875_test.zig 等倉庫文件可作為深入研讀的入口。一、快照文件是什么一段可機器驗證的編譯器行為記錄test/snapshots/dollar_prefix_record_fields.md是 Roc 編譯器基于 Zig 實現(xiàn)的**快照測試snapshot test**產(chǎn)物。它不屬于普通用戶文檔而是一份“行為契約”倉庫中的快照測試框架會執(zhí)行文件內(nèi)# SOURCE段的 Roc 代碼然后對比 token、parse 樹、警告報告、格式化結(jié)果、canonicalize IR 與推斷類型任何與# EXPECTED不一致的變化都會導致 CI 失敗相關(guān)腳本見 check_test_wiring.zig。因此這份文件精確地鎖定了$前綴在編譯管線每個階段的語義是研究該語言特性最可靠的證據(jù)源。文件的 META 段給出了它的核心斷言descriptionDollar-prefixed record labels are allowed, while a punned pattern field is checked as an immutable binding typesnippet一句話概括$前綴的記錄字段標簽是合法的但當它出現(xiàn)在 punned 模式{ $a }這種簡寫解構(gòu)中時會被當作一個不可變綁定來檢查。下面我們逐段驗證這一斷言。二、# SOURCE三種用法的完整樣例快照的源碼段展示了$前綴在三個不同語法位置的用法my_record { $field: value, ok: 1 } f |{ $a }| y g : { $b : Str } - Str g |_| x第 1 行在記錄字面量中聲明$field字段——合法無任何診斷。第 3 行在lambda 的參數(shù)模式中寫{ $a }punned 簡寫形式等價于{ $a: $a }——這里$a被視為一個不可變綁定觸發(fā)兩個警告。第 56 行在類型標注中寫{ $b : Str } - Str字段名$b同樣合法函數(shù)體用|_|丟棄參數(shù)不產(chǎn)生額外問題。三、記錄字面量與類型標注中的$完全合法3.1 記錄字面量字段名保留$前綴# EXPECTED中針對第 1 行沒有產(chǎn)生任何問題條目# PROBLEMS段的兩個report都只指向第 3 行第 810 列即源碼中的$a。這說明{ $field: value, ok: 1 }是合法的記錄字面量混合普通字段ok與$前綴字段$field沒有問題。# TOKENS段展示了詞法分析結(jié)果$field被整體詞法化為一個LowerIdent小寫標識符 token而不是被拆成符號加標識符LowerIdent,OpAssign,OpenCurly,LowerIdent,OpColon,StringStart,StringPart,StringEnd,Comma,LowerIdent,OpColon,Int,CloseCurly,這一點與 tokenize.zig 中的測試相互印證testTokenization(gpa, $foo $bar, ...)期望兩個LowerIdent且foo$bar、foo$bar$baz這類“$位于標識符中間”的寫法同樣被整體接受見src/parse/tokenize.zig第 2785、2990、3031 行附近的測試。# PARSE段的語法樹也確認字段名原樣保留(s-decl (p-ident (raw my_record)) (e-record (field (field $field) (e-string (e-string-part (raw value)))) (field (field ok) (e-int (raw 1)))))到了# CANONICALIZE規(guī)范化 IR階段$field依然作為字段名保留# TYPES段給出該記錄被推斷為{ $field: Str, ok: Dec }。這說明從詞法、語法到類型層面$前綴字段名是一條完整走通的合法路徑。配套快照 records/dollar_prefix_field_name.md 用最小樣例{ $field : value }驗證了同一結(jié)論其# FORMATTED輸出為{ $field: value }、推斷類型為{ $field: Str }。3.2 類型標注中$字段名同樣合法第 5 行g(shù) : { $b : Str } - Str在# PARSE中表現(xiàn)為(s-type-anno (name g) (ty-fn (ty-record (anno-record-field (name $b) (ty (name Str)))) (ty (name Str))))# TYPES確認其推斷類型為{ $b: Str } - Str且# PROBLEMS中沒有任何針對$b的報告。這說明$前綴只影響綁定可變性的判定不影響字段名的合法性。$前綴還被允許出現(xiàn)在更多“字段/標簽”位置。在 parse/mod.zig 的測試 dollar-prefixed record field names parse without mutability diagnostics 中以下三種場景都被驗證為無任何 tokenize/parse 診斷match value { { $field } matched } -- match 模式中的字段 app [main!] { $pf: platform ./platform/main.roc } -- app header 中的平臺標簽 package [Foo] { $dep: ../dep/main.roc } -- package header 中的依賴標簽四、punned 模式中的$不可變綁定與兩個警告4.1 發(fā)生了什么真正“有故事”的是第 3 行f |{ $a }| y。這里的{ $a }是 punned 字段模式pattern punning等價于把$a既當作字段名又當作綁定的變量名?？煺盏? EXPECTED聲明了兩個警告都指向第 3 行第 810 列即$aDOLLAR PREFIX WITHOUT VAR - dollar_prefix_record_fields.md:3:8:3:10 UNUSED VARIABLE - dollar_prefix_record_fields.md:3:8:3:10也就是說在模式里$a被判定為一個不可變綁定immutable binding而不可變綁定不允許以$開頭因此產(chǎn)生 Dollar Prefix Withoutvar同時該綁定從未被使用產(chǎn)生 Unused Variable。4.2 警告一Dollar Prefix Withoutvar# PROBLEMS段給出了編譯器生成的完整報告結(jié)構(gòu)S-expression 形式(report (severity warning) (title Dollar Prefix Without var) (region (start 3 8) (end 3 10)) (headline (reflow The immutable binding ) (annotated symbol-unqualified $a) (reflow starts with ) (annotated code $) (reflow but is not declared with ) (annotated keyword var) (reflow .)) (document (reflow Either rename this binding and all of its uses to ) (annotated symbol-unqualified a) (reflow , or declare it with ) (annotated keyword var) (reflow if it should be mutable.)))報告給出了兩條明確建議重命名把$a及其所有使用處改名為a聲明為可變?nèi)绻_實需要可變綁定用var聲明即var $a。4.3 警告二Unused Variable第二個警告針對同一區(qū)域(report (severity warning) (title Unused Variable) (region (start 3 8) (end 3 10)) (headline (reflow Variable ) (annotated symbol-unqualified $a) (reflow is defined here and then never used:)) (document (reflow If you dont need this variable, prefix it with an underscore like ) (annotated symbol-unqualified _$a) (reflow to suppress this warning.)))它的建議是如果確實用不到這個綁定把它改名為_$a來抑制警告。注意這里把$與_前綴疊加_$a說明 Roc 的命名約定中下劃線抑制未使用警告的機制對$標識符同樣適用。4.4 底層行為從 parse 到 canonicalize 的完整鏈路# PARSE中l(wèi)ambda 參數(shù)模式被解析為p-record(e-lambda (args (p-record (field (name $a) (rest false)))) (e-string (e-string-part (raw y))))到# CANONICALIZE階段模式解構(gòu)被規(guī)范化為p-record-destructure其中明確記錄了標簽與綁定標識符都是$a(e-lambda (args (p-record-destructure (destructs (record-destruct (label $a) (ident $a) (required (p-assign (ident $a))))))) (e-string (e-literal (string y))))由此可以看出編譯器處理“punned$字段”的完整邏輯先按字段標簽解構(gòu)再產(chǎn)生同名的標識符綁定隨后在綁定可變性檢查階段判定其為不可變綁定并報出警告。這條鏈路正是 ModuleEnv.zig 中binding_name_does_not_match_mutability診斷的體現(xiàn)該文件第 3961 行附近還列出了type_var_starting_with_dollar錯誤即類型變量不允許以$開頭。# TYPES段給出了第 3 行推斷出的有趣類型{ $a: _field } - a where [a.from_quote : Str - Try(a, [BadQuotedBytes(Str)])]_field是一個字段類型占位符a.from_quote約束說明這個類型變量通過“引用引號字符串”的方式被引入來自y字符串字面量的隱式from_quote轉(zhuǎn)換這是 Roc 字符串字面量“可擴展類型”機制的體現(xiàn)。4.5 格式化器不干預$前綴# FORMATTED段的結(jié)論是NO CHANGE即格式化器不會重寫或刪除$前綴字段源碼保持原樣。這與 records/dollar_prefix_field_name.md 中{ $field: value }格式化結(jié)果一致。五、與var可變性機制的聯(lián)動issue #10875 回歸測試快照語義“不可變綁定不允許$前綴”的另一面是聲明為var的可變綁定必須以$開頭。這組規(guī)則由 check/test/issue_10875_test.zig 中的回歸測試完整覆蓋該文件對應 issue #10875var無$→ 警告 Var Name Missing$var total 3; total total 1會報一次命名警告但綁定仍是可變的expectSingleNamingWarning(..., .mutable)。var $total→ 零警告顯式可變 CIRvar $total 3; $total $total 1不產(chǎn)生任何診斷且規(guī)范化后生成var_assign語句。$value無var→ 警告 Dollar Prefix Withoutvar$value 3被判定為不可變綁定報與本文快照完全相同的警告expectSingleNamingWarning(..., .immutable)。標注與定義只報一次$value : U64; $value 3以及Thing : U64.{ $identity : _; $identity ... }都只產(chǎn)生一次聲明警告。$與裸標識符是不同的標識符var $value與value可同時存在、互不影響驗證了$是標識符的組成部分而非修飾符。這組測試與本文快照互為表里快照展示“模式中的$綁定”這一具體場景回歸測試則把$與var的配對規(guī)則系統(tǒng)化——可變綁定必須寫var $x不可變綁定不能寫$x。六、實踐建議何時用$何時避開綜合快照與源碼可以給出以下可執(zhí)行的編碼規(guī)范記錄/標注的字段標簽$前綴字段名在記錄字面量、記錄類型標注、app/package header 標簽中完全合法參考 parse/mod.zig 的測試可以放心使用。它常用于標記與平臺、包依賴或互操作相關(guān)的特殊字段?？勺兘壎ㄊ褂胿ar $name形式這是唯一合法的可變綁定寫法。模式解構(gòu)中的裸$綁定|{ $a }| ...會觸發(fā)兩個警告。修復方式二選一不需要可變性時改名為a確實不用該值時改為_$a抑制未使用警告。類型變量不要以$開頭命名類型變量編譯器會報type_var_starting_with_dollar見 ModuleEnv.zig。七、小結(jié)從一份快照測試出發(fā)我們完整還原了 Roc 中$前綴標識符的語義邊界語法位置是否合法說明記錄字面量字段名{ $field: ... }? 合法字段名保留$推斷為{ $field: ... }記錄類型標注字段名{ $b : Str }? 合法不影響類型{ $b: Str } - Strapp/package header 標簽$pf、$dep? 合法見 parse/mod.zigpunned 模式綁定{ $a }?? 警告被判定為不可變綁定報 Dollar Prefix Withoutvar Unused Variable可變綁定var $x? 合法見 issue_10875_test.zig類型變量以$開頭? 錯誤type_var_starting_with_dollar這套規(guī)則的精髓在于$在 Roc 中主要服務于“可變綁定”與“特殊字段標簽”兩種角色兩者界限清晰——字段標簽位置自由使用綁定位置則必須與var配對。理解這一點就能在讀代碼、寫代碼時準確預判編譯器行為也能夠在編譯警告出現(xiàn)時第一時間定位原因?！久赓M下載鏈接】rocA fast, friendly, functional language.項目地址: https://gitcode.com/GitHub_Trending/ro/roc創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 Roc 語言 Dollar 前綴語義全解：記錄字段標簽、模式綁定與 var 可變性的邊界
Roc 語言 Dollar 前綴語義全解記錄字段標簽、模式綁定與 var 可變性的邊界【免費下載鏈接】rocA fast, friendly, functional language.項目地址: https://gitcode.com/GitHub_Trending/ro/roc導讀本篇文章基于 Roc 編譯器倉庫roc中的快照測試文件 dollar_prefix_record_fields.md系統(tǒng)講解$Dollar前綴標識符在 Roc 中的完整語義它既可以在記錄字面量與類型標注中作為字段標簽合法存在又會在記錄模式punned pattern中被解釋為一個不可變綁定從而觸發(fā) Dollar Prefix Withoutvar 與 Unused Variable 兩個編譯期警告。讀完本文你將掌握$前綴在 tokenize、parse、canonicalize 與類型推斷各階段的真實行為以及如何在實踐中正確修復相關(guān)警告。原文同時配套 dollar_prefix_field_name.md 與 issue_10875_test.zig 等倉庫文件可作為深入研讀的入口。一、快照文件是什么一段可機器驗證的編譯器行為記錄test/snapshots/dollar_prefix_record_fields.md是 Roc 編譯器基于 Zig 實現(xiàn)的**快照測試snapshot test**產(chǎn)物。它不屬于普通用戶文檔而是一份“行為契約”倉庫中的快照測試框架會執(zhí)行文件內(nèi)# SOURCE段的 Roc 代碼然后對比 token、parse 樹、警告報告、格式化結(jié)果、canonicalize IR 與推斷類型任何與# EXPECTED不一致的變化都會導致 CI 失敗相關(guān)腳本見 check_test_wiring.zig。因此這份文件精確地鎖定了$前綴在編譯管線每個階段的語義是研究該語言特性最可靠的證據(jù)源。文件的 META 段給出了它的核心斷言descriptionDollar-prefixed record labels are allowed, while a punned pattern field is checked as an immutable binding typesnippet一句話概括$前綴的記錄字段標簽是合法的但當它出現(xiàn)在 punned 模式{ $a }這種簡寫解構(gòu)中時會被當作一個不可變綁定來檢查。下面我們逐段驗證這一斷言。二、# SOURCE三種用法的完整樣例快照的源碼段展示了$前綴在三個不同語法位置的用法my_record { $field: value, ok: 1 } f |{ $a }| y g : { $b : Str } - Str g |_| x第 1 行在記錄字面量中聲明$field字段——合法無任何診斷。第 3 行在lambda 的參數(shù)模式中寫{ $a }punned 簡寫形式等價于{ $a: $a }——這里$a被視為一個不可變綁定觸發(fā)兩個警告。第 56 行在類型標注中寫{ $b : Str } - Str字段名$b同樣合法函數(shù)體用|_|丟棄參數(shù)不產(chǎn)生額外問題。三、記錄字面量與類型標注中的$完全合法3.1 記錄字面量字段名保留$前綴# EXPECTED中針對第 1 行沒有產(chǎn)生任何問題條目# PROBLEMS段的兩個report都只指向第 3 行第 810 列即源碼中的$a。這說明{ $field: value, ok: 1 }是合法的記錄字面量混合普通字段ok與$前綴字段$field沒有問題。# TOKENS段展示了詞法分析結(jié)果$field被整體詞法化為一個LowerIdent小寫標識符 token而不是被拆成符號加標識符LowerIdent,OpAssign,OpenCurly,LowerIdent,OpColon,StringStart,StringPart,StringEnd,Comma,LowerIdent,OpColon,Int,CloseCurly,這一點與 tokenize.zig 中的測試相互印證testTokenization(gpa, $foo $bar, ...)期望兩個LowerIdent且foo$bar、foo$bar$baz這類“$位于標識符中間”的寫法同樣被整體接受見src/parse/tokenize.zig第 2785、2990、3031 行附近的測試。# PARSE段的語法樹也確認字段名原樣保留(s-decl (p-ident (raw my_record)) (e-record (field (field $field) (e-string (e-string-part (raw value)))) (field (field ok) (e-int (raw 1)))))到了# CANONICALIZE規(guī)范化 IR階段$field依然作為字段名保留# TYPES段給出該記錄被推斷為{ $field: Str, ok: Dec }。這說明從詞法、語法到類型層面$前綴字段名是一條完整走通的合法路徑。配套快照 records/dollar_prefix_field_name.md 用最小樣例{ $field : value }驗證了同一結(jié)論其# FORMATTED輸出為{ $field: value }、推斷類型為{ $field: Str }。3.2 類型標注中$字段名同樣合法第 5 行g(shù) : { $b : Str } - Str在# PARSE中表現(xiàn)為(s-type-anno (name g) (ty-fn (ty-record (anno-record-field (name $b) (ty (name Str)))) (ty (name Str))))# TYPES確認其推斷類型為{ $b: Str } - Str且# PROBLEMS中沒有任何針對$b的報告。這說明$前綴只影響綁定可變性的判定不影響字段名的合法性。$前綴還被允許出現(xiàn)在更多“字段/標簽”位置。在 parse/mod.zig 的測試 dollar-prefixed record field names parse without mutability diagnostics 中以下三種場景都被驗證為無任何 tokenize/parse 診斷match value { { $field } matched } -- match 模式中的字段 app [main!] { $pf: platform ./platform/main.roc } -- app header 中的平臺標簽 package [Foo] { $dep: ../dep/main.roc } -- package header 中的依賴標簽四、punned 模式中的$不可變綁定與兩個警告4.1 發(fā)生了什么真正“有故事”的是第 3 行f |{ $a }| y。這里的{ $a }是 punned 字段模式pattern punning等價于把$a既當作字段名又當作綁定的變量名?？煺盏? EXPECTED聲明了兩個警告都指向第 3 行第 810 列即$aDOLLAR PREFIX WITHOUT VAR - dollar_prefix_record_fields.md:3:8:3:10 UNUSED VARIABLE - dollar_prefix_record_fields.md:3:8:3:10也就是說在模式里$a被判定為一個不可變綁定immutable binding而不可變綁定不允許以$開頭因此產(chǎn)生 Dollar Prefix Withoutvar同時該綁定從未被使用產(chǎn)生 Unused Variable。4.2 警告一Dollar Prefix Withoutvar# PROBLEMS段給出了編譯器生成的完整報告結(jié)構(gòu)S-expression 形式(report (severity warning) (title Dollar Prefix Without var) (region (start 3 8) (end 3 10)) (headline (reflow The immutable binding ) (annotated symbol-unqualified $a) (reflow starts with ) (annotated code $) (reflow but is not declared with ) (annotated keyword var) (reflow .)) (document (reflow Either rename this binding and all of its uses to ) (annotated symbol-unqualified a) (reflow , or declare it with ) (annotated keyword var) (reflow if it should be mutable.)))報告給出了兩條明確建議重命名把$a及其所有使用處改名為a聲明為可變?nèi)绻_實需要可變綁定用var聲明即var $a。4.3 警告二Unused Variable第二個警告針對同一區(qū)域(report (severity warning) (title Unused Variable) (region (start 3 8) (end 3 10)) (headline (reflow Variable ) (annotated symbol-unqualified $a) (reflow is defined here and then never used:)) (document (reflow If you dont need this variable, prefix it with an underscore like ) (annotated symbol-unqualified _$a) (reflow to suppress this warning.)))它的建議是如果確實用不到這個綁定把它改名為_$a來抑制警告。注意這里把$與_前綴疊加_$a說明 Roc 的命名約定中下劃線抑制未使用警告的機制對$標識符同樣適用。4.4 底層行為從 parse 到 canonicalize 的完整鏈路# PARSE中l(wèi)ambda 參數(shù)模式被解析為p-record(e-lambda (args (p-record (field (name $a) (rest false)))) (e-string (e-string-part (raw y))))到# CANONICALIZE階段模式解構(gòu)被規(guī)范化為p-record-destructure其中明確記錄了標簽與綁定標識符都是$a(e-lambda (args (p-record-destructure (destructs (record-destruct (label $a) (ident $a) (required (p-assign (ident $a))))))) (e-string (e-literal (string y))))由此可以看出編譯器處理“punned$字段”的完整邏輯先按字段標簽解構(gòu)再產(chǎn)生同名的標識符綁定隨后在綁定可變性檢查階段判定其為不可變綁定并報出警告。這條鏈路正是 ModuleEnv.zig 中binding_name_does_not_match_mutability診斷的體現(xiàn)該文件第 3961 行附近還列出了type_var_starting_with_dollar錯誤即類型變量不允許以$開頭。# TYPES段給出了第 3 行推斷出的有趣類型{ $a: _field } - a where [a.from_quote : Str - Try(a, [BadQuotedBytes(Str)])]_field是一個字段類型占位符a.from_quote約束說明這個類型變量通過“引用引號字符串”的方式被引入來自y字符串字面量的隱式from_quote轉(zhuǎn)換這是 Roc 字符串字面量“可擴展類型”機制的體現(xiàn)。4.5 格式化器不干預$前綴# FORMATTED段的結(jié)論是NO CHANGE即格式化器不會重寫或刪除$前綴字段源碼保持原樣。這與 records/dollar_prefix_field_name.md 中{ $field: value }格式化結(jié)果一致。五、與var可變性機制的聯(lián)動issue #10875 回歸測試快照語義“不可變綁定不允許$前綴”的另一面是聲明為var的可變綁定必須以$開頭。這組規(guī)則由 check/test/issue_10875_test.zig 中的回歸測試完整覆蓋該文件對應 issue #10875var無$→ 警告 Var Name Missing$var total 3; total total 1會報一次命名警告但綁定仍是可變的expectSingleNamingWarning(..., .mutable)。var $total→ 零警告顯式可變 CIRvar $total 3; $total $total 1不產(chǎn)生任何診斷且規(guī)范化后生成var_assign語句。$value無var→ 警告 Dollar Prefix Withoutvar$value 3被判定為不可變綁定報與本文快照完全相同的警告expectSingleNamingWarning(..., .immutable)。標注與定義只報一次$value : U64; $value 3以及Thing : U64.{ $identity : _; $identity ... }都只產(chǎn)生一次聲明警告。$與裸標識符是不同的標識符var $value與value可同時存在、互不影響驗證了$是標識符的組成部分而非修飾符。這組測試與本文快照互為表里快照展示“模式中的$綁定”這一具體場景回歸測試則把$與var的配對規(guī)則系統(tǒng)化——可變綁定必須寫var $x不可變綁定不能寫$x。六、實踐建議何時用$何時避開綜合快照與源碼可以給出以下可執(zhí)行的編碼規(guī)范記錄/標注的字段標簽$前綴字段名在記錄字面量、記錄類型標注、app/package header 標簽中完全合法參考 parse/mod.zig 的測試可以放心使用。它常用于標記與平臺、包依賴或互操作相關(guān)的特殊字段?？勺兘壎ㄊ褂胿ar $name形式這是唯一合法的可變綁定寫法。模式解構(gòu)中的裸$綁定|{ $a }| ...會觸發(fā)兩個警告。修復方式二選一不需要可變性時改名為a確實不用該值時改為_$a抑制未使用警告。類型變量不要以$開頭命名類型變量編譯器會報type_var_starting_with_dollar見 ModuleEnv.zig。七、小結(jié)從一份快照測試出發(fā)我們完整還原了 Roc 中$前綴標識符的語義邊界語法位置是否合法說明記錄字面量字段名{ $field: ... }? 合法字段名保留$推斷為{ $field: ... }記錄類型標注字段名{ $b : Str }? 合法不影響類型{ $b: Str } - Strapp/package header 標簽$pf、$dep? 合法見 parse/mod.zigpunned 模式綁定{ $a }?? 警告被判定為不可變綁定報 Dollar Prefix Withoutvar Unused Variable可變綁定var $x? 合法見 issue_10875_test.zig類型變量以$開頭? 錯誤type_var_starting_with_dollar這套規(guī)則的精髓在于$在 Roc 中主要服務于“可變綁定”與“特殊字段標簽”兩種角色兩者界限清晰——字段標簽位置自由使用綁定位置則必須與var配對。理解這一點就能在讀代碼、寫代碼時準確預判編譯器行為也能夠在編譯警告出現(xiàn)時第一時間定位原因?！久赓M下載鏈接】rocA fast, friendly, functional language.項目地址: https://gitcode.com/GitHub_Trending/ro/roc創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考