c# - C# 和 Java 语法是 LALR(x) 吗？

Question

我想知道 C# 和 Java 语法是否是 LALR(x)？如果是，x 的值是多少？

编辑:

接受真答案后，我觉得Q改成这样比较好:

是否有任何 LALR(x) 解析器可以解析当前版本的 Java(版本 7)或 C#(版本 4)？如果是，x 的值是多少？

Answer 1

如果不首先为一种语言指定特定的语法，你就不能问这个问题，因为有些语法可能是，有些可能不是。

也许您指的是最近 Java 规范中发布的 Java 语法。您是指 Java 7 吗？

我不确定您是否可以为 C# 指定特定的语法，至少不是来自 Microsoft 的语法，尤其是对于 C# 4.0；我不相信他们已经出版了语法。

我可以告诉你，我不认为 C# 可以是 LALR(x)，因为它有一些元素看起来像标识符，但在某些上下文中可以是关键字。这要求词法分析器知道解析器期望什么来决定一个类似标识符的标记是一个关键字，还是只是一个标识符。因此必须有从解析器到词法分析器的反馈，或者词法分析器必须产生两个标记并将它们传递给解析器以决定它想要哪个。 LALR 解析器是在 token 流上定义的，没有任何反馈，并且每个输入 token 只有一种解释。

我也不认为 Java 是从 Java 1.5 及更高版本开始的，当时 enum 是作为一种具有自己关键字的特殊类型引入的。这是因为，要让 Java 1.5 编译器处理现有的使用 enum 作为变量名的 Java 1.4 程序，enum 在某些上下文中必须被视为关键字，并且作为其他变量名。因此，Java 1.5 解析器与 C# 存在相同的问题。

实际上，没有真正的语言是 LALR(1) [第一版 Java 可能是个异常(exception)]，任何构建真正的解析器(尤其是 LALR)的人都必须进行某种破解才能解决这个问题。 (GCC 以使用 LALR 解析器解析 C++ 和糟糕的符号表很长一段时间而闻名，因此它可以区分作为变量的标识符和作为 typedef 实例的标识符之间的区别。它现在有某种手工实现的递归下降解析器，但我认为可怕的 hack 仍然存在)。所以我不确定回答你的问题的值(value)。

我们的 C# 4.0 and Java 7 members of our family of language front ends两者都使用 GLR 解析器解析语言，扩展了反馈功能，以及处理同一标记的两种解释的能力。 GLR 使 LALR(x) 的问题没有实际意义，反馈和多种解释也让我们能够处理许多超出纯 GLR 能力的语言。

编辑:经过一番思考，可能有一种非常丑陋的方式让两种语法都处理它们的上下文关键字。我们以 Java 的枚举为例。实际上必须有语法规则:

  type = 'enum' '{'  enum_members '}' ;

但我们还需要允许“枚举”作为标识符。我们可以通过替换终端 token 来做到这一点带有非终结符的标识符:

  identifier = IDENTIFIER | 'enum' ;

并坚持标识符是由词法分析器产生的终端。现在至少词法分析器不必决定如何处理enum；解析器会。但是你指定的语法必须像这样才能有机会成为 LALR(x)。

我们的解析器过去常常这样做，以允许某些关键字有时用作标识符。我们如前所述更改了解析引擎，不再这样做。