快乐的解析器规则顺序
我遇到了一个使用 Happy（Haskell 解析包）的案例，其中看似独立的规则的顺序以一种奇怪的方式影响其行为。
{
module Parser where
}
%name constFoo
%name constBar
%tokentype { Token }
%error { parseError }
%token
foo { Foo }
bar { Bar }
%%
constFoo : foo { Foo }
constBar : bar { Bar }
{
parseError :: [Token] -> a
parseError _ = error "Parse error"
data Token = Bar | Foo deriving Show
}
据我了解 Happy 的工作原理，解析 constFoo [Foo] 和 constBar [Bar] 都应该成功。但是，对于上面的代码，constFoo [Foo] 成功，但 constBar [Bar] 失败。如果我交换 constFoo 和 constBar 的规则顺序，则后者成功，前者失败。
Happy 的语义是否有某些方面我不理解？
I ran into a case using Happy (a Haskell parsing package) where the order of seemingly independent rules affects its behavior in a strange way.
{
module Parser where
}
%name constFoo
%name constBar
%tokentype { Token }
%error { parseError }
%token
foo { Foo }
bar { Bar }
%%
constFoo : foo { Foo }
constBar : bar { Bar }
{
parseError :: [Token] -> a
parseError _ = error "Parse error"
data Token = Bar | Foo deriving Show
}
As I understand how Happy works, both of the parses constFoo [Foo] and constBar [Bar] should succeed. However, with the above code, constFoo [Foo] succeeds but constBar [Bar] fails. If I swap the order of the rules for constFoo and constBar, the latter succeeds and the former fails.
Is there some aspect to Happy's semantics that I'm not understanding?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
编辑 - Happy 的语法允许您使用名称指令指定开始产生式：
这将创建一个名为 parser 的函数，并使用 constFoo 作为开始产生式。
如果您想要 constFoo 和 constBar 的解析器，这似乎是语法：
我认为在您的原始版本中，两个命名解析器函数（constFoo 和 constBar）都默认为语法中的第一个产生式（constFoo）。
Edited - Happy's syntax allows you to specify the start production with the name directive:
This creates a function called parser and it uses constFoo as the start production.
If you want parsers for both constFoo and constBar, this seems to be the syntax:
I think in your original, both named parser functions (constFoo and constBar) defaulted to the first production in the grammar (constFoo).