可以在 LALR(1) 解析器 (PLY) 中解析这种表面上的歧义吗？

Question

我在 PLY (Python Lexx Yacc) 中有一个大型语法，用于在解析方面有一些特殊挑战的语言。该语言允许两种调用的前导语法看起来几乎相同，直到调用非终端结束。这为减少/减少冲突提供了很多机会，因为沿途令牌的语义是不同的，但可以从相同的终端令牌构建。我提取了以下语法的简单前后版本，我会稍微解释一下。

最初，表达式是一种典型的“分层语法”，将调用和文字等进行初级，然后通过一元进行初级，然后将二进制变为一般表达式。问题是带有两个参数的Call_expr 与Iter_expr 的版本冲突，该版本以'/' 之前的两个ID 开头。冲突在调用中的第一个参数之后的逗号上，因为最初，Expr -> ... -> Primary_expr -> Name_expr -> Id 是允许的。解析器可以将Id 减少到Expr 以匹配Call_expr，或者让它匹配Iter_expr。展望逗号并没有帮助它做出决定。如果调用的第一个参数只是一个标识符（如变量），这是合法的歧义。考虑输入id > id ( id , id ...。

我的方法是制作一种不可能只是Id的表达式。我通过所有表达式添加了生产链，以赋予它们“_nn”版本--“不是名称”。然后我可以为Call_expr 定义产生式，在第一个参数中使用任何语法，使其不仅仅是一个名称（例如运算符、调用等），以将其简化为BinOp_expr_nn，也是 允许仅以Id 作为第一个参数的调用产生。这应该会说服解析器只是移动，直到它可以解析 Iter_expr 或 Call_expr（或者至少知道它在哪条路径上。）

正如您可能已经猜到的那样，这搞砸了一切 :)。修改表达式链也修改了Primary_expr，我仍然需要允许将其减少到Id。但现在，这是一个减少/减少冲突——每个Primary_expr 可以留在那里或继续Unary_expr。我可以命令他们做出选择（这可能会奏效），但我希望我最终会追逐一个又一个。

所以，我的问题是：是否有人可以阐明如何让相同的标记表示不同的语义（即 expr 与 id）仍然可以像 PLY 一样用 LALR(1) 解析？除此之外，还有什么有用的技巧可以帮助解决问题吗？这可以消除歧义吗？

terminals:  '+' '^' ',' '>' '(' ')' '/' ':' 'id' 'literal' 
   (i.e. punctuation (besides '->' and '|', initial-lower-case words)
non-terminals:  initial-Upper-case words

原文语法：

S'-> S
S -> Call_expr
   | Iter_expr
Expr -> BinOp_expr
BinOp_expr -> Unary_expr
BinOp_expr -> BinOp_expr '+' BinOp_expr
Unary_expr -> Primary_expr
   | '^' BinOp_expr
Primary_expr -> Name_expr
   | Call_expr
   | Iter_expr
   | Literal_expr
Name_expr -> Id
Args -> Expr
   | Args ',' Expr
Call_expr -> Primary_expr '>' Id '(' ')'
   | Primary_expr '>' Id '(' Args ')'
Iter_expr -> Primary_expr '>' Id '(' Id '/' Expr ')'
   | Primary_expr '>' Id '(' Id ':' Id '/' Expr ')'
   | Primary_expr '>' Id '(' Id ',' Id ':' Id '/' Expr ')'
Literal_expr -> literal
Id -> id

我试图消除Call_expr 中的第一个参数的歧义：

S'-> S
S -> Call_expr
   | Iter_expr
Expr -> BinOp_expr_nn
   | BinOp_expr
BinOp_expr -> BinOp_expr_nn
   | Unary_expr
BinOp_expr_nn -> Unary_expr_nn
   | BinOp_expr '+' BinOp_expr
Unary_expr -> Primary_expr
   | Unary_expr_nn
Unary_expr_nn -> Primary_expr_nn
   | '^' BinOp_expr
Primary_expr -> Primary_expr_nn
   | Name_expr
Primary_expr_nn -> Call_expr
   | Iter_expr
   | Literal_expr
Name_expr -> Id
Args -> Expr
   | Args ',' Expr
Call_expr -> Primary_expr '>' Id '(' ')'
   | Primary_expr '>' Id '(' Expr ')'
   | Primary_expr '>' Id '(' Id , Args ')'
   | Primary_expr '>' Id '(' BinOp_expr_nn , Args ')'
Iter_expr -> Primary_expr '>' Id '(' Id '/' Expr ')'
   | Primary_expr '>' Id '(' Id ':' Id '/' Expr ')'
   | Primary_expr '>' Id '(' Id ',' Id ':' Id '/' Expr ')'
Literal_expr -> literal
Id -> id

Answer 1

尽管您的帖子有标题，但您的语法并不含糊。由于您提到的原因，它根本不是 LR(1)：输入

A ( B , 

可以是Call_expr 或Iter_expr 的开头。在第一种情况下，B 必须缩减为Expr，然后再缩减为Args；在第二种情况下，它不能被减少，因为当右边的id '(' id ',' id ':' id '/' Expr ')'被减少时，它仍然需要是一个id。不能仅通过查看单个前瞻标记（，）来做出决定，因此存在移位减少冲突。

这个冲突最多可以通过两个额外的前瞻标记来解决，因为只有在 , 后面紧跟着一个 id 然后是一个 :。这样就形成了语法 LALR(3)。不幸的是，Ply 不生成 LALR(3) 解析器（yacc/bison 也不生成），但有一些替代方案。

1。使用不同的解析算法

由于语法是明确的，因此可以使用 GLR 解析器毫无问题地解析（并且无需任何修改）。 Ply 也不产生 GLR 解析器，但 Bison 可以。这可能对你没有多大用处，但我想我应该提一下，以防你没有被 Python 锁定。

2。使用允许一些无效输入的语法，并通过语义分析将其丢弃

这几乎可以肯定是最简单的解决方案，也是我通常会推荐的。如果把Iter_expr的定义改成：

Iter_expr : id '(' id '/' Expr ')'
          | id '(' Args ':' id '/' Expr ')'

那么它仍然会识别每个有效输入（因为id 和id , id 都是Args 的有效实例）。这消除了班次减少冲突；实际上，它让解析器避免在遇到 )（表示Call_expr）或 :（表示@987654336）之前做出决定@)。 （Iter_expr 的第一个替代方案没有问题，因为移动 / 而不是减少 id 的决定不需要额外的前瞻。）

当然，Iter_expr 的第二个产生式将识别出很多无效的迭代表达式：超过 2 项的列表，以及包含比单个 id 更复杂的表达式的列表。但是，这些输入根本不是有效的程序，因此可以在Iter_expr 的操作中简单地拒绝它们。识别有效迭代的精确代码将取决于您如何表示您的 AST，但这并不复杂：只需检查以确保 Args 的长度是一或二，并且列表中的每个项目只是一个id.

3。使用词法技巧

弥补前瞻信息缺失的一种方法是在词法分析器中收集信息，方法是将必要的前瞻信息收集到缓冲区中，并且仅在其句法类别已知时才输出词位。在这种情况下，词法分析器可以查找序列'(' id ',' id ':' 并标记第一个id，以便它只能在Iter_expr 中使用。在这种情况下，语法的唯一变化是：

Iter_expr : id '(' id '/' Expr ')'
          | id '(' id ':' id '/' Expr ')'
          | id '(' iter_id ',' id ':' id '/' Expr ')'

虽然这在这种特殊情况下可以正常工作，但它不是很容易维护。特别是，它依赖于能够定义一个可以在词法分析器中实现的简单且明确的模式。由于该模式是语法的简化，因此很可能未来的一些句法添加将创建一个也匹配相同模式的语法。 （这被称为词法“hack”是有原因的。）

4。求一个 LALR(1) 文法

如前所述，此语法为LALR(3)。但是没有LALR(3) 语言这样的东西。或者更准确地说，如果一种语言有LALR(k) 语法，那么它也有LALR(1) 语法，并且该语法可以从LALR(k) 语法机械地产生。此外，给定单符号前瞻文法的解析，可以重建原始文法的解析树。

因为机械生成的文法比较大，这个过程不是很吸引人，我也不知道算法的实现。相反，最常见的是尝试只重写部分语法，就像您在原始问题中所尝试的那样。这当然可以做到，但最终结果并不完全直观。

然而，这并不难。例如，这里是您的语法的一个稍微简化的版本，删除了多余的单位产生式并修复了运算符优先级（可能不正确，因为我不知道您的目标是什么语义）。

名称以N 结尾的产生式不产生ID。对于它们中的每一个，都有一个对应的产生式，没有添加ID 的N。完成后，有必要重写Args 以使用ExprN 产生式，并允许以一个或两个IDs 开头的各种参数列表。 Chain 的产生只是为了避免一些重复。

Start   : Call
        | Iter
Expr    : ID
        | ExprN
ExprN   : UnaryN
        | Expr '+' Unary
Unary   : ID
        | UnaryN
UnaryN  : ChainN
        | '^' Chain
Chain   : ID
        | ChainN
ChainN  : PrimaryN
        | Chain '>' CallIter
PrimaryN: LITERAL
        | Call
        | Iter
        | '(' Expr ')'
Call    : ID '(' ')'
        | ID '(' ID ')'
        | ID '(' ID ',' ID ')'
        | ID '(' Args ')'
Iter    : ID '(' ID '/' Expr ')'
        | ID '(' ID ':' ID '/' Expr ')'
        | ID '(' ID ',' ID ':' ID '/' Expr ')'
Args    : ExprN ExprList
        | ID ',' ExprN ExprList
        | ID ',' ID ',' Expr ExprList
ExprList:
        | ExprList ',' Expr

我没有像我想要的那样测试这个，但我认为它产生了正确的语言。