【问题标题】:What causes Happy to throw a parse error?是什么导致 Happy 抛出解析错误?
【发布时间】:2015-08-13 19:06:56
【问题描述】:

我已经用 Alex 编写了一个词法分析器,我正在尝试将它连接到一个用 Happy 编写的解析器。我会尽量在不粘贴大量代码的情况下总结我的问题。

我从我的词法分析器的单元测试中知道字符串 "\x7" 被词法化为:

[TokenNonPrint '\x7', TokenEOF]

我的令牌类型(由词法分析器吐出)是Token。我已经按照here 的描述定义了lexWrapalexEOF,这给了我以下标头和令牌声明:

%name parseTokens 
%tokentype { Token }
%lexer { lexWrap } { alexEOF }
%monad { Alex }
%error { parseError }

%token
  NONPRINT {TokenNonPrint $$}
  PLAIN { TokenPlain $$ }

我使用以下内容调用解析器+词法分析器组合:

parseExpr :: String -> Either String [Expr]
parseExpr s = runAlex s parseTokens

这是我最初的几部作品:

exprs :: { [Expr] }
exprs
  : {- empty -} { trace "exprs 30" [] }
  | exprs expr { trace "exprs 31" $ $2 : $1 }

nonprint :: { Cmd }
  : NONPRINT { NonPrint $ parseNonPrint $1}

expr :: { Expr }
expr
  : nonprint {trace "expr 44" $ Cmd $ $1}
  | PLAIN { trace "expr 37" $ Plain $1 }

我将省略 ExprNonPrint 的数据类型声明,因为它们很长,这里只有构造函数 CmdNonPrint 重要。函数parseNonPrint 在 Parse.y 的底部定义为:

parseNonPrint :: Char -> NonPrint
parseNonPrint '\x7' = Bell

另外,我的错误处理函数如下:

parseError :: Token -> Alex a
parseError tokens = error ("Error processing token: " ++ show tokens)

这样写,我希望下面的 hspec 测试通过:

parseExpr "\x7" `shouldBe` Right [Cmd (NonPrint Bell)]

但相反,我看到"exprs 30" print 一次(即使我正在运行 5 个不同的单元测试)并且我对parseExpr 的所有测试都返回Right []。我不明白为什么会这样,但我更改了 exprs 生产以防止它:

exprs :: { [Expr] }
exprs
  : expr { trace "exprs 30" [$1] }
  | exprs expr { trace "exprs 31" $ $2 : $1 }

现在我的所有测试都在他们命中的第一个令牌上失败 --- parseExpr "\x7" 失败:

uncaught exception: ErrorCall (Error processing token: TokenNonPrint '\a')

我非常困惑,因为我希望解析器采用路径 exprs -> expr -> nonprint -> NONPRINT 并成功。我不明白为什么这个输入会使解析器处于错误状态。没有trace 语句被命中(优化了吗?)。

我做错了什么?

【问题讨论】:

  • 你能指出我们的代码 - 即 github repo 吗?
  • @user5402 github.com/pscollins/ansi-parser 拥有所有代码。目前有点草率,尤其是测试的标签。

标签: parsing haskell happy alex


【解决方案1】:

原来这个错误的原因是无害的线

%lexer { lexWrap } { alexEOF }

这是由有关使用 Alex 和 Happy 的链接问题推荐的(不幸的是,这是“使用 Alex 作为 Happy 的单子词法分析器”等查询的顶级 Google 结果之一。解决方法是将其更改为以下内容:

%lexer { lexWrap } { TokenEOF }

我必须深入研究生成的代码才能发现问题。它是由派生自 %tokens 指令的代码引起的,如下所示(我在尝试追踪错误时注释掉了除 TokenNonPrint 之外的所有令牌声明):

happyNewToken action sts stk
    = lexWrap(\tk -> 
    let cont i = happyDoAction i tk action sts stk in
    case tk of {
    alexEOF -> happyDoAction 2# tk action sts stk; -- !!!!
    TokenNonPrint happy_dollar_dollar -> cont 1#;
    _ -> happyError' tk
    })

显然,Happy 将%tokens 指令的每一行转换为模式匹配的一个分支。它%lexer 指令中被标识为EOF 标记的任何内容插入一个分支。

通过插入值的名称alexEOF,而不是数据构造函数TokenEOF,case 语句的此分支具有将名称alexEOF 重新绑定到传入的任何标记的效果lexWrap,隐藏原始绑定并短路 case 语句,使其每次都符合 EOF 规则,这不知何故导致 Happy 进入错误状态。

类型系统没有发现错误,因为标识符alexEOF(或TokenEOF)没有出现在生成的代码中的其他任何地方。像这样滥用 %lexer 指令会导致 GHC 发出警告,但是,由于警告出现在生成的代码中,因此无法将其与代码抛出的所有其他无害警告区分开来。

【讨论】:

    猜你喜欢
    • 2018-06-17
    • 2017-04-17
    • 2011-08-04
    • 1970-01-01
    • 1970-01-01
    • 2019-04-03
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多