“愉快”的含义，例如：你可以用“自然”的方式编写语法，而不必以复杂的方式重写它们，而不必引入无聊的样板。
让我们为这个问题的目的规定，除非技术的表现在病态上是不好的，否则表现不是最重要的问题。
尽管如此，你可能想提一下，当出于性能原因而不得不重写语法时，技术是否会失败。
在回答此问题时，请让我了解您使用过的语法的大小和复杂程度。此外，您是否使用了相关技术的任何值得注意的“高级”功能，以及您对这些功能的印象。
当然，这个问题的答案可能取决于域名，在这种情况下，我很乐意了解这一事实。
答案 0 :(得分：29)
这真的取决于你的开始和你想做什么。没有一个适合所有人。
如果有LR语法（例如你使用的是Yacc语法），将它转换为适合Parsec或uu-parsinglib的LL语法是一项很好的工作。然而，许多sepBy等解析器在这里非常有用，但你应该期望解析器比Happy + Alex慢。
对于LL组合子解析，uu-parsinglib和它的前任uu-parsing很不错，但它们缺少像Parsec的Token和Language模块这样的东西，所以可能不太方便。有些人喜欢Malcolm Wallace的Parselib，因为他们与Parsec有不同的模型用于回溯，但我没有经验。
如果要解码某些格式化文件而不是编程语言，Attoparsec或类似文件可能比Parsec或uu-parsinglib更好。更好的是在这种情况下更快 - 不仅仅是ByteString与Char，但我认为Attoparsec在错误处理/源位置跟踪方面做的工作较少，因此解析器应该运行得更快，因为它们每个输入元素的工作量更少。
另外，请记住，文本文件格式可能并不总是具有语法，因此您可能必须定义一些自定义组合器来执行特殊的词法技巧，而不是仅为每个元素定义“解析器组合器”。
对于LR解析，我发现Ralf Hinze的Frown比Happy更好 - 更好的错误支持和更好的语法文件格式但Frown没有主动维护而且不在Hackage上。我认为它是LR（k）而不是LR（1），这意味着它更强大w.r.t.展望。
表现并不是一个很大的问题w.r.t.一个语法。编程语言有复杂的语法，但你可以期待相当小的文件。至于数据文件格式，格式的设计者真的应该以这样的方式设计它，以便它允许有效的解析。对于组合器解析器，您不需要为数据格式文件提供许多高级功能 - 如果这样做，要么格式设计不当（有时会发生这种情况）或者您的解析器是。
为了记录，我编写了一个带有Frown的GL解析器，带有Happy的GL着色语言，带有UU_Parsing的未完成的C语法分析器，以及Parsec的很多东西。对我的选择是我的开始，LR语法 - 皱眉或快乐（现在没有保持快乐皱眉），否则通常是Parsec（因为我说uu_parse很好但缺乏LanguageDef的便利）。对于二进制格式，我自己动手，但我通常有特殊要求。
答案 1 :(得分：5)
我们使用'uu-parsinglib'取得了巨大的成功 - 我们已经从Parsec切换到了它，因为它更加灵活和强大 - 例如，它可以支持延迟解析，如果需要，你不需要明确使用组合器（如Parsec中的'try'）来标记可能的反向跟踪点。
确实，目前你需要在事物的标记化方面做更多的事情，但对于我们来说，相对于图书馆的基本优势而言，这是一个小点。
答案 2 :(得分：5)
最近，我在uu-parsinglib中重新设计了一个用parsec编写的DSL解析器。我发现它大大简化了程序。我的主要动机是获得自动纠正方面。这才有效。它实际上是免费的！另外，我更倾向于以应用风格编写我的解析器而不是Parsec的monadic风格。