具有错误恢复的GLR解析器：输入错误时有太多选择

Question

序言

我编写了GLR-parser并进行了错误恢复。当遇到错误时，它会分成以下备选方案：

1. 将预期元素插入输入（可能是用户错过了它）并照常进行。
2. 将错误的元素替换为预期的元素（可能是用户只是输错了）并照常进行。
3. 跳过错误的元素，如果下一个元素也是错误的，那么请转到＃2。

但是如果输入有很多错误（例如，用户错误地将JPEG文件提供给解析器），则许多替代方案会呈指数级增长。

示例

这样的解析器对应于以下语法：

Program -> Identifier WS Identifier WS '=' WS Identifier
Identifier -> ('a'..'z' | 'A'..'Z' | '0'..'9')*
WS -> ' '*

适用于以下文字：

x = "abc\"def"; y = "ghi\"jkl";

在中等规模的现代台式电脑上因“内存不足”而失败。

问题

如果输入错误，如何减少备选方案的数量？

Answer 1

可以在字符级别执行GLR（因此解析）错误纠正，但会加剧您的问题。

我们使用的GLR错误恢复程序对令牌进行操作，因此它并没有那么糟糕。

但是当输入有大量错误时，很难恢复。更复杂的错误恢复方案基本上使用解析器来识别输入中语言的有效子串，然后尝试将子串一起修补以获得结果。那是非常雄心勃勃的。

我已经构建了错误恢复的GLR解析器。我不那么野心勃勃。一般来说 当实时解析器的数量超过“大数”（例如，10,000）或者遇到的语法错误的数量超过阈值（例如，10或20）时，解析器大多只是中止。如果解析器在最后一秒没有提升输入流，你可以考虑中止它，这是一个间接的标志，它有太多的实时解析器。