用于语言翻译的 ANTLR4 解析器（平面解析器与结构解析器）

Question

在过去的几个月里，在本网站成员的帮助下，我已经能够编写（第一阶段）一个 Lexer 和 Parser 来将 Lang X 翻译成 Java。因为我是这个主题的新手，所以我选择了一个简单的逐行解析器，现在它能够在 15 分钟内解析大约 1000 个语言文件，并且出现少量错误/异常和大约 1M 行代码，问题被隔离到源文件而不是解析器。为了更好的表达，我将其称为平面解析。

现在进入第 2 阶段，即转换为 Java。像任何语言一样，我的有数据结构、过程、子例程等，我认为最好从下面更改解析器（为简单起见，我专注于数据结构（称为 TABLE））：

// Main entry point of the program
program
   : executableUnit+ EOF
   ;
   
// Execution units (line by line)
executableUnit:
    |   itemBlockStart
    |   itemBlockEnd
    |   itemStatement
    |   tableHeader
;

itemBlockStart: BEGIN;
itemBlockEnd:   END;
tableHeader: // A TABLE declaration statement
    TABLE atom LETTER (atom)*
;
// Item statement
itemStatement:
        // Tables with Item statements
        ITEM atom+
// Base atom lowest of the low
atom:
        MINUS? INT              #IntegerAtom
    |   REAL_FORMAT             #RealAtom
    |   FIX_POINT               #FixPointAtom
    |   (MINUS | EQUALS)? NAME DOT?     #NameAtom
    |   LETTER                  #LetterAtom
    |   keywords DOT?           #KeywordAtom
    |   DOLLAR atom DOLLAR      #DollarAtom
    |   hex_assign              #HexItem
    ;               

到这里：

// Execution units (by structure)
executableUnit:
        tableStatement
    |   itemStatement
;

// Table statement, header and body
tableStatement:
    tableHeader (itemBlockStart | itemBlockEnd | itemStatement)*;

在我们继续之前，TABLE 和单独的 ITEM 语句可以出现在代码中的任何地方，它们自己（Java 输出将是公共的）或在过程中（Java 输出将是私有的）

想象一下，当解析器产生相同数量的错误，但解析输入的时间要长 10 倍时，我会感到沮丧（如果你愿意的话）。在选择正确的道路方面，我有点理解增加的时间段。我对小组的问题是：

1. 有没有办法强制解析器提前关闭 TABLE 结构以减少时间段？
2. 具有这种逻辑树结构分组是否值得增加时间？

我希望朝这个方向发展的愿望是有一个带有迷你树的 Listener 回调，其中所有相关项目都可以访问。 IE。如果过程语句中的迷你树不在 Java 中是公共的。

Answer 1

我并不完全清楚你指的是什么性能差异（大概是“逐行”解析器和这个完整文件解析器之间的差异。（？？？）

一些关于你的语法“跳出”的事情，可能会对性能产生一些影响：

1 - itemBlockStart: BEGIN; 和 itemBlockEnd: END;。有一个单一令牌的规则是没有意义的。只需在规则定义中使用令牌即可。

2 - 在此规则 (tableStatement: tableHeader (itemBlockStart | itemBlockEnd | itemStatement)*;) 中，您可能无意中对itemStartBlock 和itemStopBlock 的接受程度非常 放松。这也可能对性能产生影响。我假设在此回复的其余部分中，BEGIN 应该出现在 itemStatement 的开头，END 应该出现在末尾（并不是这三个可以以任何顺序出现）。

试试这个重构：

// Main entry point of the program
program
   : executableUnit+ EOF
   ;
   
// Execution units (line by line)
executableUnit:
    |   itemStatement  # ItemStmt
    |   tableHeader    # TableHeader
;

tableHeader: // A TABLE declaration statement
    TABLE atom LETTER atom*
;

// Item statement
itemStatement: // Tables with Item statements
    BEGIN ITEM atom+ END
;

// Base atom lowest of the low
atom:   MINUS? INT              #IntegerAtom
    |   REAL_FORMAT             #RealAtom
    |   FIX_POINT               #FixPointAtom
    |   (MINUS | EQUALS)? NAME DOT?     #NameAtom
    |   LETTER                  #LetterAtom
    |   keywords DOT?           #KeywordAtom
    |   DOLLAR atom DOLLAR      #DollarAtom
    |   hex_assign              #HexItem
    ;  

诚然，我不太清楚你的意图是什么，但这应该是朝着正确方向迈出的一步。

正如 Kaby76 所指出的，tableHeader 末尾的贪婪运算符很可能会“吞噬”大量输入。这部分是因为缺少终止令牌（毫无疑问，这会在没有终止令牌之前停止令牌消耗。但是，您的 atom 规则似乎有点像可以匹配所有输入方式的“厨房水槽”规则。再加上atom+ 和atom* 的使用，很有可能会消耗大量令牌。@987654334 中的任何一个真的是你的意图吗@s 可以在没有结构的情况下一个接一个地出现？它们似乎是表达式的片段/部分。如果是这种情况，您将需要为表达式定义语法。这种添加的结构既有助于提高性能，又能为您提供更多有用的解析树。

很像您问题语法中tableStatement 的结构，它并不真正代表任何结构（请参阅我的建议将其更改为BEGIN ITEM atom+ END，而不是接受任何顺序的任何组合。同样的思考过程需要应用于atom。这两种方法都让 ANTLR 遍历您的代码，消耗大量令牌，而没有任何关于订单是否实际正确的线索（然后在出现问题时尝试“退出”非常昂贵遇到）。