Javacc无法访问的声明

Question

在我的语法中,有表达式和片段的生成规则,最初包含间接左递归.这是我从它们中删除递归后的规则.

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()
}

如果有人能帮助告诉我为什么会出现这个问题,那将非常有帮助.

Answer 1

你有

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"作为条件,即使它是数字.如果你意识到这一点并设计了编译器的其余部分,那么一切仍然有效,不会造成任何伤害.

这种方法的另一个缺点是理论上解析现在是二次时间.我不认为这是一个严重的问题.