LALR 解析器生成器可以选择使用不可解析的输入吗?

Can LALR parser generators optionally consume unparsable input?

提问人:cornuz 提问时间:11/3/2023 最后编辑:cornuz 更新时间:11/10/2023 访问量:125

问:

我正在转换现有的解析器,从使用解析器组合器到使用解析器生成器。

更具体地说,这是在 Haskell 项目中,解析器正在从 using 转向 using (-like) 和 (-like)。但是,我认为问题更普遍地与这两种方法有关。megaparsecalexflexhappybison

考虑以下陈述:if-then-else

if (condition) then_block else else_block

以及一个重要的细节,即条件可以在此 DSL 的解析时解析(即 语句将始终在解析时解析为任一分支,并且永远不会像在 AST 中那样结束), 解析器组合器自上而下的特性允许我正确解析部分不正确的语句,例如:if-then-elseif-then-else

if (4 > 2) {
  <correct statements>
} else {
  <correct statements>
  <INCORRECT statement>  /* for example containing unresolved placeholders */
}

这是因为一旦条件被评估为可以在不实际解析的情况下消耗整体,如下所示:trueelse_block

ifelseStmt
  = do  reserved "if"
        e <- parens expression
        if evalBoolExpr e then do
          b <- block
          option [] (reserved "else" *> unparsedBlock $> [])
          return b
        else do unparsedBlock
                option [] (reserved "else" *> block)

unparsedBlock
  = do  hidden $ L.skipBlockCommentNested "{" "}"
        whiteSpace

注意:想要这种冒险行为可能看起来很奇怪,但是在使用此 DSL 的特定设置中,始终可以保证条件绑定到选择没有错误语句的分支。

问题:

使用自下而上的工具方法,其中词法处理基本上独立于解析上下文,我看不出如何实现相同的结果。 可能吗?flex/bison

中的当前生产规则,该规则将无法解析上述示例中的 else 块:happy

ifelse_statement :: { [Statement] }
  : 'if' '(' expr ')' statement_block 'else' statement_block {
      if evalBoolExpr $3 then $5 else $7
    }
解析 Haskell Happy Alex

评论


答: 暂无答案