戰(zhàn)：解析樹與 AST 的取舍，以及如何解耦輸入遍歷與輸出生成)
ANTLR 4 翻譯實(shí)戰(zhàn)解析樹與 AST 的取舍以及如何解耦輸入遍歷與輸出生成【免費(fèi)下載鏈接】antlr4ANTLR (ANother Tool for Language Recognition) is a powerful parser generator for reading, processing, executing, or translating structured text or binary files.項(xiàng)目地址: https://gitcode.com/gh_mirrors/an/antlr4本文基于 doc/faq/translation.md 展開。這篇 FAQ 回答了使用 ANTLR 4 做翻譯型任務(wù)從一種語言/文本到另一種表示如生成代碼、字節(jié)碼或另一門語言時(shí)的兩個(gè)核心設(shè)計(jì)問題到底該用具體的解析樹還是專門的 AST以及如何把遍歷輸入與生成輸出徹底解耦。讀完本文你將理解 ANTLR 4 中 parse tree、AST、listener/visitor、StringTemplate 各自的定位并能落地中間模型驅(qū)動(dòng)輸出這一經(jīng)典翻譯架構(gòu)。背景ANTLR 4 語境下的翻譯在 ANTLR 4 的 FAQ 目錄doc/faq/index.md中Translation與 Parse Trees、Actions and semantic predicates 并列專門討論把解析結(jié)果進(jìn)一步加工成目標(biāo)產(chǎn)物的方法論。與解釋執(zhí)行不同翻譯型任務(wù)關(guān)注的是從輸入構(gòu)造輸出代碼生成器把源碼翻譯成字節(jié)碼、匯編或另一門高級(jí)語言格式化工具把自由格式文本翻譯成規(guī)范排版DSL 編譯器把領(lǐng)域語言翻譯成宿主語言調(diào)用。在這種場(chǎng)景下兩個(gè)問題幾乎必然出現(xiàn)解析樹parse tree夠用嗎要不要像傳統(tǒng)編譯器那樣先構(gòu)造一棵抽象語法樹AST如何組織代碼才能讓讀懂輸入的邏輯與寫出輸出的邏輯互不糾纏、可獨(dú)立演進(jìn)FAQ 的作者也是 ANTLR 的作者結(jié)合自身從編譯轉(zhuǎn)向翻譯的經(jīng)驗(yàn)給出了明確的方法論下面的小節(jié)逐一展開。AST 與解析樹選哪個(gè)兩者的本質(zhì)區(qū)別解析樹parse tree / concrete syntax tree完整記錄文法規(guī)則如何匹配輸入的樹。內(nèi)部節(jié)點(diǎn)是規(guī)則上下文RuleContext葉子節(jié)點(diǎn)是詞法記號(hào)TerminalNode保留著輸入的完整結(jié)構(gòu)、括號(hào)、運(yùn)算符寫法等表層語法。在 ANTLR 4 中Parser每次匹配都會(huì)自動(dòng)構(gòu)建這棵樹無需任何額外代碼。ASTabstract syntax tree經(jīng)過語義提煉的樹只保留后續(xù)處理類型檢查、翻譯、求值真正需要的節(jié)點(diǎn)丟棄括號(hào)、關(guān)鍵字、分隔符等冗余信息并且節(jié)點(diǎn)通常被重構(gòu)為更接近語義的形態(tài)例如運(yùn)算符節(jié)點(diǎn)帶優(yōu)先級(jí)信息。FAQ 作者的經(jīng)驗(yàn)多數(shù)時(shí)候解析樹就夠FAQ 原文明確寫道作者過去習(xí)慣為編譯、生成字節(jié)碼/匯編而構(gòu)造專門的 AST 節(jié)點(diǎn)但當(dāng)思考重心轉(zhuǎn)向翻譯之后開始直接使用解析樹到了 v4他意識(shí)到自己做的大多數(shù)工作其實(shí)都是翻譯。作者的判斷是生成字節(jié)碼時(shí)解析樹或許不如 AST 順手。以 Lisp 風(fēng)格前綴表達(dá)式和文法風(fēng)格中綴表達(dá)式對(duì)比( 3 4) ← 語義上更干凈利于生成字節(jié)碼 (expr 3 4) ← 解析樹保留的形態(tài)需要額外處理運(yùn)算符位置也就是說對(duì)字節(jié)碼生成這類對(duì)樹形極度敏感的場(chǎng)景AST 的規(guī)整形態(tài)運(yùn)算在前、操作數(shù)在后確實(shí)更友好。但作者同時(shí)強(qiáng)調(diào)這并非世界末日——翻譯任務(wù)中解析樹的信息完整性往往比 AST 的規(guī)整性更有價(jià)值。什么情況下才需要 ASTdoc/faq/parse-trees.md 對(duì)寫編譯器需要 AST 怎么辦給出了三條可行路徑與本文互為補(bǔ)充生成 LLVM 風(fēng)格的 SSA 形式直接作為中間表示用 listener 或 visitor 從解析樹構(gòu)造 AST——這是最經(jīng)典的做法解析樹保留完整輸入你在遍歷時(shí)只提取需要的語義信息重建一棵新樹在文法中直接嵌入 action并關(guān)閉自動(dòng)解析樹構(gòu)建ANTLR 4 支持parser/lexer選項(xiàng)關(guān)閉上下文對(duì)象生成徹底放棄解析樹由 action 邊匹配邊產(chǎn)出 AST。三條路徑的取舍本質(zhì)上是解析樹是自動(dòng)獲得、信息最全的原始數(shù)據(jù)AST 是手工提煉、面向下游需求的工作數(shù)據(jù)。翻譯型任務(wù)如果下游對(duì)樹形不敏感直接消費(fèi)解析樹可以省掉 AST 層的全部維護(hù)成本——這正是 v4 作者大多時(shí)候用解析樹的原因。解耦輸入遍歷與輸出生成中間模型 模板核心思想讓輸出由內(nèi)部模型驅(qū)動(dòng)而非輸入形態(tài)驅(qū)動(dòng)FAQ 提出的建議非常具體創(chuàng)建一個(gè)代表輸出的中間模型intermediate model。你遍歷解析樹去收集信息、構(gòu)建這個(gè)模型然后幾乎可以自動(dòng)地遍歷這個(gè)內(nèi)部模型用與內(nèi)部模型類名匹配的 StringTemplate來生成輸出。也就是說定義一個(gè)專門的IFStatement對(duì)象字段齊全然后在遍歷解析樹時(shí)把這些對(duì)象逐個(gè)創(chuàng)建出來。輸入與輸出的解耦是極其強(qiáng)大的。解析樹上有 listener 接口但這并不意味著解析樹本身必然是承載生成代碼所需的全部信息的最佳數(shù)據(jù)結(jié)構(gòu)。FAQ 舉了一個(gè)極端例子假設(shè)輸出恰好是輸入的完全反轉(zhuǎn)。此時(shí)你只應(yīng)該遍歷輸入來收集數(shù)據(jù)輸出的生成必須由內(nèi)部模型驅(qū)動(dòng)而不是由輸入在解析樹中的表示方式驅(qū)動(dòng)。如果直接把輸出邏輯掛在解析樹上反轉(zhuǎn)需求會(huì)把代碼寫得支離破碎有了中間模型輸出邏輯只認(rèn)識(shí)模型與輸入語法徹底無關(guān)。為什么解析樹不適合直接充當(dāng)輸出數(shù)據(jù)源解析樹與具體文法一一綁定文法一改比如把expr : expr term改成expr : term ( term)*整棵樹的形狀就變了所有掛在樹上的輸出邏輯全部要跟著改。而中間模型描述的是目標(biāo)產(chǎn)物如一個(gè) IF 語句條件 Xthen 分支 Yelse 分支 Z與輸入文法無關(guān)。文法演進(jìn)時(shí)只需調(diào)整解析樹 → 中間模型這一段輸出側(cè)紋絲不動(dòng)。結(jié)合源碼看 listener 機(jī)制如何支持收集信息FAQ 提到的walk the parse tree to collect information在 ANTLR 4 中有直接實(shí)現(xiàn)。以 Java 運(yùn)行時(shí)為例ParseTreeWalker.java 的walk()對(duì)樹做深度優(yōu)先遞歸進(jìn)入規(guī)則節(jié)點(diǎn)先觸發(fā)enterRule遞歸完所有子節(jié)點(diǎn)再觸發(fā)exitRule遇到TerminalNode/ErrorNode則觸發(fā)對(duì)應(yīng)回調(diào)。這個(gè)進(jìn)入/退出結(jié)構(gòu)天然適合在進(jìn)入時(shí)收集上下文、退出時(shí)完成一個(gè)模型對(duì)象。ParseTreeListener.java 定義了最小回調(diào)集visitTerminal、visitErrorNode、enterEveryRule、exitEveryRule由 ANTLR 工具為每個(gè)文法生成的XListener接口再細(xì)化出每個(gè)規(guī)則的enterXxx/exitXxx方法。ParseTreeProperty.java 基于IdentityHashMap為解析樹節(jié)點(diǎn)掛接任意屬性適合在 listener 各事件方法之間傳遞該子樹的中間結(jié)果——例如把每個(gè)表達(dá)式子樹的求值結(jié)果掛回對(duì)應(yīng)節(jié)點(diǎn)供父規(guī)則取用。一個(gè)典型的遍歷輸入、構(gòu)建模型的 listener 骨架如下假設(shè)文法含規(guī)則ifstat : if expr then stmt ( else stmt )? ;public class MyListener extends ExprBaseListener { // 中間模型與輸出一一對(duì)應(yīng)與輸入語法無關(guān) static class IFStatement { String condition; String thenBranch; String elseBranch; } private final ListIFStatement model new ArrayList(); Override public void exitIfstat(ExprParser.IfstatContext ctx) { IFStatement stmt new IFStatement(); stmt.condition tokens.getText(ctx.expr()); // 從 TokenStream 取源文本 stmt.thenBranch tokens.getText(ctx.stmt(0)); stmt.elseBranch ctx.stmt(1) ! null ? tokens.getText(ctx.stmt(1)) : null; model.add(stmt); // 收集進(jìn)中間模型 } }這里ctx.stmt(1) ! null的判斷方式與 FAQ 中測(cè)試可選規(guī)則是否匹配的慣例一致見 doc/faq/actions-preds.md可寫成$expr.ctx ! null或$EQUALS ! null這說明 listener 里拿到的ParserRuleContext本身就是解析樹的規(guī)則節(jié)點(diǎn)getText()等能力全部可用。關(guān)于取文本FAQ 的姊妹篇 doc/faq/parse-trees.md 給出了精確定位ParseTree.getText()只拼接葉子節(jié)點(diǎn)文本、不含隱藏通道如注釋/空白ParseTree.java若要按源碼區(qū)間完整還原文本應(yīng)使用TokenStream.getText(RuleContext)如 BufferedTokenStream.java 所示——即mytokens.getText(mySubTree)。用 StringTemplate 從內(nèi)部模型生成輸出FAQ 強(qiáng)調(diào)用與內(nèi)部模型類名匹配的 StringTemplate 自動(dòng)生成輸出。這并非設(shè)想而是ANTLR 工具自身就在實(shí)踐的架構(gòu)從源碼看ANTLR 4 的代碼生成分為兩步tool/src/org/antlr/v4/codegen 包先由ParserFactory/OutputModelController把文法編譯產(chǎn)物組織成一組 Java 的OutputModelObject模型對(duì)象再由 OutputModelWalker.java 遍歷模型、以StringTemplateorg.stringtemplate.v4.STGroup見 CodeGenerator.java按模型類名查找對(duì)應(yīng)模板渲染出最終的XParser.java、XLexer.java等目標(biāo)代碼。也就是說模型是數(shù)據(jù).stg模板是視圖兩者靠類名約定解耦。你的翻譯器完全可以照搬這套模式// 1. 遍歷解析樹構(gòu)建中間模型見上一節(jié)的 listener ListIFStatement statements walk(parseTree); // 2. 加載與模型類名匹配的 StringTemplate 組 STGroup templates new STGroupFile(Output.stg); // 3. 遍歷內(nèi)部模型自動(dòng)按類名渲染 for (IFStatement s : statements) { ST st templates.getInstanceOf(ifStatement); // 類名 → 模板名 st.add(cond, s.condition); st.add(then, s.thenBranch); st.add(else, s.elseBranch); out.println(st.render()); }對(duì)應(yīng)的Output.stg模板片段ifStatement(cond, then, else) :: if (cond) { then } if(else) else { else } endif 這套解析樹 → 中間模型 → 模板輸出三段式正是 FAQ 建議解耦后的完整形態(tài)文法只影響第一段輸出格式只影響第三段中間模型是兩者的穩(wěn)定契約。為什么不建議把輸出邏輯直接寫進(jìn) listener/visitorFAQ 的隱含警告是listener/visitor 的存在容易誘使你直接在回調(diào)里拼輸出。這會(huì)把三種關(guān)注點(diǎn)揉成一團(tuán)樹形結(jié)構(gòu)知識(shí)哪個(gè)節(jié)點(diǎn)在哪個(gè)上下文——屬于輸入側(cè)語義計(jì)算符號(hào)、類型、作用域——屬于分析側(cè)目標(biāo)文本排版縮進(jìn)、換行、引號(hào)轉(zhuǎn)義——屬于輸出側(cè)。一旦混在一起遇到輸出是輸入的反轉(zhuǎn)這類需求或文法調(diào)整導(dǎo)致樹形變化代碼將難以維護(hù)。正確姿勢(shì)是listener 只負(fù)責(zé)從解析樹提取數(shù)據(jù)并填充模型必要時(shí)借助 ParseTreeProperty.java 暫存子樹的中間結(jié)果輸出完全交給模型 模板。另外如果你偏好返回值式遍歷可用 visitor 替代 listenerANTLR 為每個(gè)文法生成XVisitor基類 AbstractParseTreeVisitor.java 已實(shí)現(xiàn)visitChildren的聚合邏輯defaultResult初始化、aggregateResult合并子結(jié)果、shouldVisitNextChild可短路visitor 每層返回中間值天然適合自底向上構(gòu)建模型。兩者選型的完整討論listener/visitor vs XPath vs 樹模式匹配見 doc/faq/parse-trees.mdlistener/visitor 能力最強(qiáng)但要實(shí)現(xiàn)的方法最多XPath如//vardecl適合定位特定節(jié)點(diǎn)樹模式匹配如x expr;適合按具體語法形態(tài)找子樹。在翻譯架構(gòu)中XPath 和樹模式匹配更適合作為對(duì)解析樹做快速探查的輔助手段而主線仍是 listener/visitor 構(gòu)建中間模型。實(shí)踐建議一個(gè)可復(fù)用的翻譯流水線綜合 FAQ 兩個(gè)主題落地一個(gè)翻譯器時(shí)建議遵循以下層次解析LexerParser產(chǎn)出自動(dòng)構(gòu)建的解析樹無需任何 AST 代碼分析/收集XBaseListener或XBaseVisitor深度優(yōu)先遍歷解析樹收集符號(hào)、作用域、依賴關(guān)系構(gòu)建中間模型需要跨節(jié)點(diǎn)共享狀態(tài)時(shí)用作用域棧進(jìn)入類/函數(shù) push、退出 popscopeStack.peek().define(...)或在節(jié)點(diǎn)上掛ParseTreeProperty參考 doc/faq/parse-trees.md 中符號(hào)表管理的例子建模為每種輸出結(jié)構(gòu)定義專門的模型類IFStatement、FunctionDecl……字段只描述輸出需要什么不摻入輸入語法細(xì)節(jié)渲染StringTemplate 組按模型類名約定渲染輸出代碼、文檔或任何目標(biāo)格式格式調(diào)整只改.stg模板。這一流水線把 FAQ 的兩條主線——解析樹優(yōu)先必要時(shí)才造 AST與用中間模型 模板解耦輸入與輸出——串聯(lián)為可直接照抄的工程范式也是 ANTLR 4 官方 FAQ 對(duì)翻譯型應(yīng)用給出的最終答案。【免費(fèi)下載鏈接】antlr4ANTLR (ANother Tool for Language Recognition) is a powerful parser generator for reading, processing, executing, or translating structured text or binary files.項(xiàng)目地址: https://gitcode.com/gh_mirrors/an/antlr4創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 ANTLR 4 翻譯實(shí)戰(zhàn)：解析樹與 AST 的取舍，以及如何解耦輸入遍歷與輸出生成
ANTLR 4 翻譯實(shí)戰(zhàn)解析樹與 AST 的取舍以及如何解耦輸入遍歷與輸出生成【免費(fèi)下載鏈接】antlr4ANTLR (ANother Tool for Language Recognition) is a powerful parser generator for reading, processing, executing, or translating structured text or binary files.項(xiàng)目地址: https://gitcode.com/gh_mirrors/an/antlr4本文基于 doc/faq/translation.md 展開。這篇 FAQ 回答了使用 ANTLR 4 做翻譯型任務(wù)從一種語言/文本到另一種表示如生成代碼、字節(jié)碼或另一門語言時(shí)的兩個(gè)核心設(shè)計(jì)問題到底該用具體的解析樹還是專門的 AST以及如何把遍歷輸入與生成輸出徹底解耦。讀完本文你將理解 ANTLR 4 中 parse tree、AST、listener/visitor、StringTemplate 各自的定位并能落地中間模型驅(qū)動(dòng)輸出這一經(jīng)典翻譯架構(gòu)。背景ANTLR 4 語境下的翻譯在 ANTLR 4 的 FAQ 目錄doc/faq/index.md中Translation與 Parse Trees、Actions and semantic predicates 并列專門討論把解析結(jié)果進(jìn)一步加工成目標(biāo)產(chǎn)物的方法論。與解釋執(zhí)行不同翻譯型任務(wù)關(guān)注的是從輸入構(gòu)造輸出代碼生成器把源碼翻譯成字節(jié)碼、匯編或另一門高級(jí)語言格式化工具把自由格式文本翻譯成規(guī)范排版DSL 編譯器把領(lǐng)域語言翻譯成宿主語言調(diào)用。在這種場(chǎng)景下兩個(gè)問題幾乎必然出現(xiàn)解析樹parse tree夠用嗎要不要像傳統(tǒng)編譯器那樣先構(gòu)造一棵抽象語法樹AST如何組織代碼才能讓讀懂輸入的邏輯與寫出輸出的邏輯互不糾纏、可獨(dú)立演進(jìn)FAQ 的作者也是 ANTLR 的作者結(jié)合自身從編譯轉(zhuǎn)向翻譯的經(jīng)驗(yàn)給出了明確的方法論下面的小節(jié)逐一展開。AST 與解析樹選哪個(gè)兩者的本質(zhì)區(qū)別解析樹parse tree / concrete syntax tree完整記錄文法規(guī)則如何匹配輸入的樹。內(nèi)部節(jié)點(diǎn)是規(guī)則上下文RuleContext葉子節(jié)點(diǎn)是詞法記號(hào)TerminalNode保留著輸入的完整結(jié)構(gòu)、括號(hào)、運(yùn)算符寫法等表層語法。在 ANTLR 4 中Parser每次匹配都會(huì)自動(dòng)構(gòu)建這棵樹無需任何額外代碼。ASTabstract syntax tree經(jīng)過語義提煉的樹只保留后續(xù)處理類型檢查、翻譯、求值真正需要的節(jié)點(diǎn)丟棄括號(hào)、關(guān)鍵字、分隔符等冗余信息并且節(jié)點(diǎn)通常被重構(gòu)為更接近語義的形態(tài)例如運(yùn)算符節(jié)點(diǎn)帶優(yōu)先級(jí)信息。FAQ 作者的經(jīng)驗(yàn)多數(shù)時(shí)候解析樹就夠FAQ 原文明確寫道作者過去習(xí)慣為編譯、生成字節(jié)碼/匯編而構(gòu)造專門的 AST 節(jié)點(diǎn)但當(dāng)思考重心轉(zhuǎn)向翻譯之后開始直接使用解析樹到了 v4他意識(shí)到自己做的大多數(shù)工作其實(shí)都是翻譯。作者的判斷是生成字節(jié)碼時(shí)解析樹或許不如 AST 順手。以 Lisp 風(fēng)格前綴表達(dá)式和文法風(fēng)格中綴表達(dá)式對(duì)比( 3 4) ← 語義上更干凈利于生成字節(jié)碼 (expr 3 4) ← 解析樹保留的形態(tài)需要額外處理運(yùn)算符位置也就是說對(duì)字節(jié)碼生成這類對(duì)樹形極度敏感的場(chǎng)景AST 的規(guī)整形態(tài)運(yùn)算在前、操作數(shù)在后確實(shí)更友好。但作者同時(shí)強(qiáng)調(diào)這并非世界末日——翻譯任務(wù)中解析樹的信息完整性往往比 AST 的規(guī)整性更有價(jià)值。什么情況下才需要 ASTdoc/faq/parse-trees.md 對(duì)寫編譯器需要 AST 怎么辦給出了三條可行路徑與本文互為補(bǔ)充生成 LLVM 風(fēng)格的 SSA 形式直接作為中間表示用 listener 或 visitor 從解析樹構(gòu)造 AST——這是最經(jīng)典的做法解析樹保留完整輸入你在遍歷時(shí)只提取需要的語義信息重建一棵新樹在文法中直接嵌入 action并關(guān)閉自動(dòng)解析樹構(gòu)建ANTLR 4 支持parser/lexer選項(xiàng)關(guān)閉上下文對(duì)象生成徹底放棄解析樹由 action 邊匹配邊產(chǎn)出 AST。三條路徑的取舍本質(zhì)上是解析樹是自動(dòng)獲得、信息最全的原始數(shù)據(jù)AST 是手工提煉、面向下游需求的工作數(shù)據(jù)。翻譯型任務(wù)如果下游對(duì)樹形不敏感直接消費(fèi)解析樹可以省掉 AST 層的全部維護(hù)成本——這正是 v4 作者大多時(shí)候用解析樹的原因。解耦輸入遍歷與輸出生成中間模型 模板核心思想讓輸出由內(nèi)部模型驅(qū)動(dòng)而非輸入形態(tài)驅(qū)動(dòng)FAQ 提出的建議非常具體創(chuàng)建一個(gè)代表輸出的中間模型intermediate model。你遍歷解析樹去收集信息、構(gòu)建這個(gè)模型然后幾乎可以自動(dòng)地遍歷這個(gè)內(nèi)部模型用與內(nèi)部模型類名匹配的 StringTemplate來生成輸出。也就是說定義一個(gè)專門的IFStatement對(duì)象字段齊全然后在遍歷解析樹時(shí)把這些對(duì)象逐個(gè)創(chuàng)建出來。輸入與輸出的解耦是極其強(qiáng)大的。解析樹上有 listener 接口但這并不意味著解析樹本身必然是承載生成代碼所需的全部信息的最佳數(shù)據(jù)結(jié)構(gòu)。FAQ 舉了一個(gè)極端例子假設(shè)輸出恰好是輸入的完全反轉(zhuǎn)。此時(shí)你只應(yīng)該遍歷輸入來收集數(shù)據(jù)輸出的生成必須由內(nèi)部模型驅(qū)動(dòng)而不是由輸入在解析樹中的表示方式驅(qū)動(dòng)。如果直接把輸出邏輯掛在解析樹上反轉(zhuǎn)需求會(huì)把代碼寫得支離破碎有了中間模型輸出邏輯只認(rèn)識(shí)模型與輸入語法徹底無關(guān)。為什么解析樹不適合直接充當(dāng)輸出數(shù)據(jù)源解析樹與具體文法一一綁定文法一改比如把expr : expr term改成expr : term ( term)*整棵樹的形狀就變了所有掛在樹上的輸出邏輯全部要跟著改。而中間模型描述的是目標(biāo)產(chǎn)物如一個(gè) IF 語句條件 Xthen 分支 Yelse 分支 Z與輸入文法無關(guān)。文法演進(jìn)時(shí)只需調(diào)整解析樹 → 中間模型這一段輸出側(cè)紋絲不動(dòng)。結(jié)合源碼看 listener 機(jī)制如何支持收集信息FAQ 提到的walk the parse tree to collect information在 ANTLR 4 中有直接實(shí)現(xiàn)。以 Java 運(yùn)行時(shí)為例ParseTreeWalker.java 的walk()對(duì)樹做深度優(yōu)先遞歸進(jìn)入規(guī)則節(jié)點(diǎn)先觸發(fā)enterRule遞歸完所有子節(jié)點(diǎn)再觸發(fā)exitRule遇到TerminalNode/ErrorNode則觸發(fā)對(duì)應(yīng)回調(diào)。這個(gè)進(jìn)入/退出結(jié)構(gòu)天然適合在進(jìn)入時(shí)收集上下文、退出時(shí)完成一個(gè)模型對(duì)象。ParseTreeListener.java 定義了最小回調(diào)集visitTerminal、visitErrorNode、enterEveryRule、exitEveryRule由 ANTLR 工具為每個(gè)文法生成的XListener接口再細(xì)化出每個(gè)規(guī)則的enterXxx/exitXxx方法。ParseTreeProperty.java 基于IdentityHashMap為解析樹節(jié)點(diǎn)掛接任意屬性適合在 listener 各事件方法之間傳遞該子樹的中間結(jié)果——例如把每個(gè)表達(dá)式子樹的求值結(jié)果掛回對(duì)應(yīng)節(jié)點(diǎn)供父規(guī)則取用。一個(gè)典型的遍歷輸入、構(gòu)建模型的 listener 骨架如下假設(shè)文法含規(guī)則ifstat : if expr then stmt ( else stmt )? ;public class MyListener extends ExprBaseListener { // 中間模型與輸出一一對(duì)應(yīng)與輸入語法無關(guān) static class IFStatement { String condition; String thenBranch; String elseBranch; } private final ListIFStatement model new ArrayList(); Override public void exitIfstat(ExprParser.IfstatContext ctx) { IFStatement stmt new IFStatement(); stmt.condition tokens.getText(ctx.expr()); // 從 TokenStream 取源文本 stmt.thenBranch tokens.getText(ctx.stmt(0)); stmt.elseBranch ctx.stmt(1) ! null ? tokens.getText(ctx.stmt(1)) : null; model.add(stmt); // 收集進(jìn)中間模型 } }這里ctx.stmt(1) ! null的判斷方式與 FAQ 中測(cè)試可選規(guī)則是否匹配的慣例一致見 doc/faq/actions-preds.md可寫成$expr.ctx ! null或$EQUALS ! null這說明 listener 里拿到的ParserRuleContext本身就是解析樹的規(guī)則節(jié)點(diǎn)getText()等能力全部可用。關(guān)于取文本FAQ 的姊妹篇 doc/faq/parse-trees.md 給出了精確定位ParseTree.getText()只拼接葉子節(jié)點(diǎn)文本、不含隱藏通道如注釋/空白ParseTree.java若要按源碼區(qū)間完整還原文本應(yīng)使用TokenStream.getText(RuleContext)如 BufferedTokenStream.java 所示——即mytokens.getText(mySubTree)。用 StringTemplate 從內(nèi)部模型生成輸出FAQ 強(qiáng)調(diào)用與內(nèi)部模型類名匹配的 StringTemplate 自動(dòng)生成輸出。這并非設(shè)想而是ANTLR 工具自身就在實(shí)踐的架構(gòu)從源碼看ANTLR 4 的代碼生成分為兩步tool/src/org/antlr/v4/codegen 包先由ParserFactory/OutputModelController把文法編譯產(chǎn)物組織成一組 Java 的OutputModelObject模型對(duì)象再由 OutputModelWalker.java 遍歷模型、以StringTemplateorg.stringtemplate.v4.STGroup見 CodeGenerator.java按模型類名查找對(duì)應(yīng)模板渲染出最終的XParser.java、XLexer.java等目標(biāo)代碼。也就是說模型是數(shù)據(jù).stg模板是視圖兩者靠類名約定解耦。你的翻譯器完全可以照搬這套模式// 1. 遍歷解析樹構(gòu)建中間模型見上一節(jié)的 listener ListIFStatement statements walk(parseTree); // 2. 加載與模型類名匹配的 StringTemplate 組 STGroup templates new STGroupFile(Output.stg); // 3. 遍歷內(nèi)部模型自動(dòng)按類名渲染 for (IFStatement s : statements) { ST st templates.getInstanceOf(ifStatement); // 類名 → 模板名 st.add(cond, s.condition); st.add(then, s.thenBranch); st.add(else, s.elseBranch); out.println(st.render()); }對(duì)應(yīng)的Output.stg模板片段ifStatement(cond, then, else) :: if (cond) { then } if(else) else { else } endif 這套解析樹 → 中間模型 → 模板輸出三段式正是 FAQ 建議解耦后的完整形態(tài)文法只影響第一段輸出格式只影響第三段中間模型是兩者的穩(wěn)定契約。為什么不建議把輸出邏輯直接寫進(jìn) listener/visitorFAQ 的隱含警告是listener/visitor 的存在容易誘使你直接在回調(diào)里拼輸出。這會(huì)把三種關(guān)注點(diǎn)揉成一團(tuán)樹形結(jié)構(gòu)知識(shí)哪個(gè)節(jié)點(diǎn)在哪個(gè)上下文——屬于輸入側(cè)語義計(jì)算符號(hào)、類型、作用域——屬于分析側(cè)目標(biāo)文本排版縮進(jìn)、換行、引號(hào)轉(zhuǎn)義——屬于輸出側(cè)。一旦混在一起遇到輸出是輸入的反轉(zhuǎn)這類需求或文法調(diào)整導(dǎo)致樹形變化代碼將難以維護(hù)。正確姿勢(shì)是listener 只負(fù)責(zé)從解析樹提取數(shù)據(jù)并填充模型必要時(shí)借助 ParseTreeProperty.java 暫存子樹的中間結(jié)果輸出完全交給模型 模板。另外如果你偏好返回值式遍歷可用 visitor 替代 listenerANTLR 為每個(gè)文法生成XVisitor基類 AbstractParseTreeVisitor.java 已實(shí)現(xiàn)visitChildren的聚合邏輯defaultResult初始化、aggregateResult合并子結(jié)果、shouldVisitNextChild可短路visitor 每層返回中間值天然適合自底向上構(gòu)建模型。兩者選型的完整討論listener/visitor vs XPath vs 樹模式匹配見 doc/faq/parse-trees.mdlistener/visitor 能力最強(qiáng)但要實(shí)現(xiàn)的方法最多XPath如//vardecl適合定位特定節(jié)點(diǎn)樹模式匹配如x expr;適合按具體語法形態(tài)找子樹。在翻譯架構(gòu)中XPath 和樹模式匹配更適合作為對(duì)解析樹做快速探查的輔助手段而主線仍是 listener/visitor 構(gòu)建中間模型。實(shí)踐建議一個(gè)可復(fù)用的翻譯流水線綜合 FAQ 兩個(gè)主題落地一個(gè)翻譯器時(shí)建議遵循以下層次解析LexerParser產(chǎn)出自動(dòng)構(gòu)建的解析樹無需任何 AST 代碼分析/收集XBaseListener或XBaseVisitor深度優(yōu)先遍歷解析樹收集符號(hào)、作用域、依賴關(guān)系構(gòu)建中間模型需要跨節(jié)點(diǎn)共享狀態(tài)時(shí)用作用域棧進(jìn)入類/函數(shù) push、退出 popscopeStack.peek().define(...)或在節(jié)點(diǎn)上掛ParseTreeProperty參考 doc/faq/parse-trees.md 中符號(hào)表管理的例子建模為每種輸出結(jié)構(gòu)定義專門的模型類IFStatement、FunctionDecl……字段只描述輸出需要什么不摻入輸入語法細(xì)節(jié)渲染StringTemplate 組按模型類名約定渲染輸出代碼、文檔或任何目標(biāo)格式格式調(diào)整只改.stg模板。這一流水線把 FAQ 的兩條主線——解析樹優(yōu)先必要時(shí)才造 AST與用中間模型 模板解耦輸入與輸出——串聯(lián)為可直接照抄的工程范式也是 ANTLR 4 官方 FAQ 對(duì)翻譯型應(yīng)用給出的最終答案。【免費(fèi)下載鏈接】antlr4ANTLR (ANother Tool for Language Recognition) is a powerful parser generator for reading, processing, executing, or translating structured text or binary files.項(xiàng)目地址: https://gitcode.com/gh_mirrors/an/antlr4創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考