使用参考手册语法分析Ada 2005作用域标识符时的堆栈溢出问题

Question

我目前正在使用Pyparsing和参考手册语法规则实现ada2005解析器。我们需要这样做，以便分析和转换我们的老化艾达代码库的部分C/C++。在

大多数事情都有效。在

然而，还有一个小问题仍然存在：

语法规则name在分析作用域标识符（rule所选的组件）时失败，例如表达式"Global_Types.Integer2"，因为它是左关联语法规则循环的一部分。在

我认为这条规则写得不对：子规则direct_name应该放在子规则direct_name之后。事实上，它应该排在备选方案的最后。否则，direct_name和{}只匹配和"Global_Types"，然后期望字符串在此之后结束。不是我想要的。在

因此，我现在将规则direct_name移到name-alternatives的末尾……但是我得到了一个Pyparsing无限递归，Python抛出的递归深度超过了最大值。在

我相信这个问题是因为

• 语法规则所选构件的关联性是从右到左。我搜索了Pyparsing的参考手册，但是没有找到任何相关的东西。我们应该把点（.）看作是一个具有从右到左结合性的运算符，还是可以通过扩展和重组语法规则来解决它？

• 或者说Pyparsing无限递归中没有检查。我相信这不会太难实现。使用从当前活动规则（函数）到源位置/偏移量（getTokensEndLoc()）的映射，如果当前源输入位置/偏移量等于与刚刚输入的规则相关的位置，则始终会使规则失败。

Recursive expressions with pyparsing可能与我的问题有关。在

这个问题似乎也与Need help in parsing part of python grammar密切相关 不幸的是还没有答案。在

以下是导致无限递归的Ada 2005语法规则循环：

• name=>
• selected_component=>
• prefix=>
• name

注意，这个问题不是Ada特有的问题，而是与包含左递归规则的所有语法相关。在

Answer 1

作为参考，如GNAT: The GNU Ada Compiler，§2.2 The Parser中所述，ARM中给出的Ada语法是不明确的，表驱动的解析器将被迫修改语法以使其为LL（1）或LALR（1）技术所接受