我应该如何构造和遍历ANTLR3语法的AST输出？

Question

文档和一般建议是，抽象语法树应该省略没有任何意义的标记。(“只记录有意义的输入标记”-最终的ANTLR引用) IE:在C++ AST中，您将省略类开始和结束时的大括号，因为它们没有任何意义，只是用于为解析目的划分类开始和结束的一种机制。我知道，为了快速高效地遍历树，剔除像这样无用的令牌节点是有用的，但是为了适当地对代码进行着色，我需要这些信息，即使它对代码的意义没有任何帮助。A)为什么我不应该让AST服务于多个目的，并且选择不省略所述的令牌？

在我看来，ANTLRWorks解释器输出的是我要找的东西。在ANTLRWorks解释器中，它输出一个树形图，为每个匹配的规则生成一个节点，并为每个令牌和/或子规则输出一个子节点。解析树，我想它叫做。

如果手动遍历一棵树，那么让节点标记规则不是更有用吗？通过让一个节点标记一个规则，并将它的子规则和标记作为子规则，手动步行器不需要向前看几个节点，就可以知道它正在运行的节点的上下文。树语法在我看来是多余的。给定一个AST节点树，树语法再次对节点进行“解析”，以产生其他输出。( B)由于解析器语法负责生成正确的AST，并且给定规则AST节点的包含，难道手工游行者不应该避免树形语法的冗余AST节点模式匹配吗？

我恐怕我误解了树语法机制的目的。树语法或多或少定义了一组方法，这些方法将在树中运行，查找与树语法规则匹配的节点模式，并在此基础上执行一些操作。我不能依赖于根据树语法的整洁性(为模式匹配速度省略无意义的标记)来形成AST输出，而是将AST用于颜色编码，甚至是无意义的标记。我也在编写IDE；我也不能编写插件作者想要匹配的所有可能的AST节点模式，也不想要求他们使用ANTLR编写树语法。在插件作者为自己的标准遍历树的情况下，规则节点对于避免需要模式匹配非常有用。

有什么想法？我知道这个“问题”可能会推到“如此问题”的极限，但我不知道该如何表达我的问题，也不知道该在哪里查询。

Answer 1

Sion Sheevok写道：

A)为什么我不应该让AST服务于多个目的，并且选择不省略所述的令牌？

不，你最好把他们关在里面。

Sion Sheevok写道：

在我看来，ANTLRWorks解释器输出的是我要找的东西。在ANTLRWorks解释器中，它输出一个树形图，为每个匹配的规则生成一个节点，并为每个令牌和/或子规则输出一个子节点。解析树，我想它叫做。

对，是这样。

Sion Sheevok写道：

( B)由于解析器语法负责生成正确的AST，并且给定规则AST节点的包含，难道手工游行者不应该避免树形语法的冗余AST节点模式匹配吗？

树语法通常用于混合自定义代码来计算/解释输入源。如果将这些代码混合到解析器语法中，并且在解析器中进行了一些回溯，那么这个自定义代码可能会执行得比预期的要多。使用树语法遍历树(如果正确的话)只可能以一种方式导致只执行一次自定义代码。

但是，如果需要一个单独的树遍历器/迭代器，那么有两个阵营主张使用树语法，其他人则选择使用自定义迭代器手动遍历树。两个阵营都对他们喜欢的步行方式提出了正确的观点。所以没有明确的方法可以用一种特定的方式来做。

Sion Sheevok写道：

有什么想法？

由于您没有评估/解释，您也不介意使用树语法。

但是，要像ANTLRWorks那样创建解析树(顺便说一句，您无法访问)，您需要在解析器语法中混合AST重写规则。这里有一个Q&A来解释如何做到这一点：How to output the AST built using ANTLR?

祝好运!