在我的语法中,最初包含间接左递归的表达式和片段有生成规则。这是我删除递归后的规则。
String expression() #Expression : {String number; Token t;}
{
number = fragment()
(
(t = <Mult_Sign> number = fragment())
)
{return number;}
}
String fragment() #void : {String t;}
{
t = identifier() {return t;}
| t = number() {return t;}
| (<PLUS> | <MINUS> ) fragment()
| <LBR> expression() <RBR>
}
当试图解析语法中的条件时,将使用这些生成规则。然而,生成规则的排序要么有它,所以只接受表达式。然而,它应该接受while(x<=10)这样的东西。如果我有相反顺序的产生式规则,如语法中最初所述。当我尝试使用javac编译java文件时。我收到一个错误,告诉我identifier()是一个无法访问的语句。这是条件生成规则:
void condition() #void : {Token t;}
{
<NOT> expression()
| expression (<EQUALS>|<NOTEQUALS>|<LT>|<GT>|<LTE>|<GTE>|<AND>|<OR>) expression()
| identifier()
}
如果有人能告诉我为什么会出现这个问题,那将是非常有帮助的。
您有
void condition() #void : {Token t;}
{
/*a*/ <NOT> expression()
/*b*/ | expression (<EQUALS>|<NOTEQUALS>|<LT>|<GT>|<LTE>|<GTE>|<AND>|<OR>) expression()
/*c*/ | identifier()
}
如果解析器正在寻找一个条件,它将尝试根据下一个输入令牌在三个备选方案之间做出选择。如果该令牌是标识符,则存在问题,因为备选方案(b)或备选方案(c)都可以工作。面对选择冲突,JavaCC更喜欢第一个,因此将选择(b)。如果下一个令牌不是标识符,那么将不选择备选方案(c)。因此,无论哪种方式,都无法达到备选方案(c)。
这是你的问题。该怎么办?这是通常的解决方案。
如果希望在表达式中允许更多的运算符,请使用更多的非终结符来表示更高级别的优先级。例如
condition --> expression
expression --> disjunct (OR expression)?
disjunct --> conjunct (AND disjunct)?
conjunct --> comparand ((EQ|NEQ|LT|GT|LE|GE) comparand)?
comparand --> term ((PLUS|MINUS) term)*
term --> fragment ((TIMES | DIVIDE) fragment)*
fragment --> identifier | number | LBR expression RBR | (PLUS|MINUS|NOT) fragment
这个语法可以接受你想要的一切,甚至更多。例如,如果你有
statement --> WHILE condition DO statement
您的解析器将接受例如"WHILE a+b DO a:=b"。在许多语言中,这是通过类型检查来解决的;Java就是这样做的。在其他语言中,它是通过允许各种事情作为条件来处理的;LISP就是这么做的。
关于NOT 优先级的注记
大多数语言都认为NOT的优先级很高,就像这个答案的第二部分一样。这具有消除所有选择警告的良好效果,因为语法是LL(1)。
然而,如果您希望一元运算符具有较低的优先级,那么如果您使用JavaCC,实际上没有什么可以阻止您。例如,您可以将碎片更改为
fragment --> identifier | number | LBR expression RBR | (PLUS|MINUS) fragment | NOT conjunct
现在语法不是LL(1)(它甚至不明确)。因此JavaCC会给出一些选择冲突警告。但它实际上会将"NOT a LT b"解析为"NOT(a LT b)"
几乎没有一种语言能做到的是我认为你正在努力做到的,那就是限制语法,这样只有看起来像条件的表达式才被允许作为条件。如果这确实是您想要的,那么您可以使用JavaCC使用语法前瞻来实现。以下是你的操作方法。
从这样的语法开始。(这基本上是你的想法,更多地关注优先级。)
condition --> disjunct (OR condition)?
disjunct --> conjunct (AND disjunct)?
conjunct --> expression (EQ|NEQ|LT|GT|LE|GE) expression
| LBR condition RBR
| NOT conjunct
| identifier
expression --> term ((PLUS|MINUS) term)*
term --> fragment ((TIMES | DIVIDE) fragment)*
fragment --> identifier | number | LBR expression RBR | (PLUS|MINUS) fragment
这是一个明确的条件语法。然而,当下一个令牌是标识符或LBR时,它在连接时会发生选择冲突。为了解决这种选择冲突,您可以使用语法前瞻来查找比较运算符,因此
void conjunct() : { } {
LOOKAHEAD( expression() (<EQ>|<NEQ>|<LT>|<GT>|<LE>|<GE>) )
expression() (<EQ>|<NEQ>|<LT>|<GT>|<LE>|<GE>) expression()
| LBR condition() RBR
| NOT conjunct()
| identifier() {
那么,为什么(几乎)没有编程语言是这样做的呢?大多数语言都有布尔类型的变量,所以像您一样,允许标识符作为条件。所以你仍然需要进行类型检查来排除"WHILE i do…",其中"i"不是布尔类型。此外,你应该使用什么语法进行赋值?你需要
statement --> identifier := (expression | condition) | ...
即使是句法前瞻也不会告诉你"x:=y"的哪个选择是正确的。这是一个模棱两可的语法。
如果在两个选项都解析的情况下,任何一个选项都是可以接受的,那么在这里也可以使用语法前瞻。
void statement() : {} {
identifier <BECOMES> (LOOKAHEAD(condition()) condition()) | expression())
| ...
}
这将把"x:=y"中的"y"解析为一个条件,即使它是数字。如果您意识到了这一点,并设计了编译器的其余部分,使一切都能正常工作,就不会造成任何伤害。
这种方法的另一个缺点是解析现在在理论上是二次时间。我不认为这是一个严重的问题。