我正在尝试使用Lark为BASIC创建一个LALR解析器,并且我很难修复"END“语句和"END IF”等语句之间的冲突。以下是该语法的简化版本:
%ignore /[ \t\f]+/
program: _nlopt _part_list
_part_list: (stmt | block) _nl _part_list
|
_nlopt: _nl
|
_nl: _NEWLINE _nl
| _NEWLINE
block: if_block
stmt: print_stmt
| end_stmt
end_stmt: END_KW
if_block: IF_KW expr THEN_KW _nl block_body endif_stmt
endif_stmt: END_KW IF_KW
block_body: _block_body_item block_body
|
_block_body_item: stmt _nl
print_stmt: PRINT_KW expr
?expr: NUMERIC_LITERAL
_NEWLINE: "\n"
NUMERIC_LITERAL: /[\-+]?\d+(\.\d*)?[!#%&]?/
END_KW: "end"i
IF_KW: "if"i
PRINT_KW: "print"i
THEN_KW: "then"i
如果我用下面这样的代码尝试这个语法:
parser = Lark(grammar, start='program', parser='lalr')
prog = r"""
if 1 then
print 200
end if
"""
t = parser.parse(prog)
print(t.pretty())
这是我从Lark那里得到的:
Traceback (most recent call last):
File "test.py", line 230, in <module>
t = parser.parse(prog)
File "/home/user/.pyenv/versions/venv/lib/python3.6/site-packages/lark/lark.py", line 250, in parse
return self.parser.parse(text)
File "/home/user/.pyenv/versions/venv/lib/python3.6/site-packages/lark/parser_frontends.py", line 37, in parse
return self.parser.parse(token_stream, *[sps] if sps is not NotImplemented else [])
File "/home/user/.pyenv/versions/venv/lib/python3.6/site-packages/lark/parsers/lalr_parser.py", line 68, in parse
for token in stream:
File "/home/user/.pyenv/versions/venv/lib/python3.6/site-packages/lark/lexer.py", line 341, in lex
for x in l.lex(stream, self.root_lexer.newline_types, self.root_lexer.ignore_types):
File "/home/user/.pyenv/versions/venv/lib/python3.6/site-packages/lark/lexer.py", line 175, in lex
raise UnexpectedCharacters(stream, line_ctr.char_pos, line_ctr.line, line_ctr.column, allowed=allowed, state=self.state)
lark.exceptions.UnexpectedCharacters: No terminal defined for 'i' at line 4 col 5
end if
^
Expecting: ['__IGNORE_0', '_NEWLINE']
如果我删除"end_stmt“规则,这将不会发生。有没有办法修复语法,使这种情况不会发生?
发布于 2019-05-10 21:50:23
默认情况下,Lark不会警告您语法中存在shift-reduce冲突,而是静默地解决这些冲突,以支持shift。通常,这会导致解析器无法解析您想要的内容-就像这里的情况一样。您可以通过将debug = True
标志传递给Lark()
来使lark就此类冲突向您发出警告。这样,您甚至可以在通过测试发现问题之前就发现问题所在,甚至可以获得有关问题所在位置的有用信息。
启用debug
选项后,您将收到一条警告,提示存在shift-reduce冲突,其中END_KW
可能意味着当前block_body
已结束,也可能是end_stmt
。这是一个问题,因为LALR(1)解析器只能向前看一个令牌,但我们必须向前看第二个令牌,看看在end
之后是否有if
才能正确地决定采用哪个选项。
您可以通过将end if
转换为单个令牌来修复此问题,如下所示:
ENDIF_KW: /end[ \t\f]+if/i
然后使用ENDIF_KW
而不是END_KW IF_KW
。
PS:请注意,如果您使用Earley解析而不是LALR(1),您的语法将在没有这些更改的情况下工作得很好。
发布于 2019-05-22 11:30:17
我和我的基本语法也有同样的冲突。basic语言是LALR(2)或LR(2),因为有END WHILE、END IF等。如果你有一个LR(2)解析器生成器,你可以解析Basic。LRSTAR解析器生成器可以创建LR(2)解析器。
https://stackoverflow.com/questions/56079928
复制