哪种Haskell解析技术最易于使用，为什么？

Question

例如，"Pleasant“的意思是:你可以以一种”自然“的方式编写语法，而不必以令人费解的方式重写它们，也不必引入无聊的样板文件。

为了这个问题的目的，让我们规定，除非一项技术的性能是病态的糟糕，否则性能不是这里最大的问题。

不过，话虽如此，您可能想要提到，当出于性能原因而不得不重写语法时，一项技术是否会失败。

在回答这个问题时，请告诉我你使用过的语法的大小和复杂性。此外，您是否使用过相关技术的任何值得注意的“高级”功能，以及您对这些功能的印象如何。

当然，这个问题的答案可能取决于领域，在这种情况下，我很乐意了解这一事实。

Answer 1

这真的取决于你从什么开始，以及你想做什么。没有一刀切的办法。

如果你有LR文法(例如，你是从Yacc文法开始工作的)，把它转换成适用于Parsec或uu-parsinglib的LL文法是一项很大的工作。然而，许多解析器、sepBy等解析器在这里非常有用，但您应该期望解析器比Happy+Alex更慢。

对于LL combinator解析，uu-parsinglib和它的前身uu-parsing很好，但它们缺少类似Parsec的标记和语言模块，因此可能不太方便。有些人喜欢Malcolm Wallace的Parselib，因为他们有不同于Parsec的回溯模型，但我对他们没有经验。

如果你正在解码一些格式化的文件而不是像编程语言那样的东西，Attoparsec或类似的可能比Parsec或uu-parsinglib更好。在这种情况下更快-不仅仅是ByteString与Char，而且我认为Attoparsec在错误处理/源位置跟踪方面做的工作更少，所以解析器应该运行得更快，因为它们在每个输入元素上做的工作更少。

此外，请记住，文本文件格式可能并不总是具有这样的语法，因此您可能必须定义一些自定义组合符来执行特殊的词法技巧，而不仅仅是为每个元素定义“解析器组合符”。

对于LR解析，我发现Ralf Hinze的Frown比Happy更好-更好的错误支持和更好的语法文件格式，但Frown不是主动维护的，也不是Hackage。我认为它是LR(k)而不是LR(1)，这意味着它更强大。向前看。

性能实际上并不是一个很大的问题。一种语法。编程语言有复杂的语法，但你可以期待相当小的文件。至于数据文件格式，它确实应该是格式的设计者设计它的方式，它允许有效的解析。对于combinator解析器，您不应该为数据格式文件需要太多高级特性-如果需要，要么是格式设计不佳(不幸的是有时会发生这种情况)，要么是您的解析器设计糟糕。

根据记录，我已经用Frown写了一个C解析器，用Happy写了GL-shading语言，用UU_Parsing写了一个未完成的C解析器，用Parsec写了很多东西。我的选择是我开始的，LR语法-皱眉或快乐(现在快乐如皱眉不维护)，否则通常是Parsec (正如我所说的uu_parse很好，但缺乏LanguageDef的便利性)。对于二进制格式，我使用自己的格式，但我通常有特殊的要求。

Answer 2

最近，我在uu-parsinglib中重铸了一个用parsec编写的DSL解析器。我发现它极大地简化了程序。我的主要动机是获得自动校正方面。这很管用。它实际上是免费的！此外，我更喜欢以应用风格编写解析器，而不是Parsec的一元风格。

Answer 3

我们使用'uu-parsinglib‘取得了巨大的成功--我们从Parsec切换到了它，因为它更加灵活和强大--例如，如果需要的话，它可以支持惰性解析，而且你不需要显式地使用组合符(就像Parsec中的'try’)来标记可能的回溯点。

诚然，目前您需要在标记化方面做更多的工作，但对于我们来说，相对于库的基本优势来说，这只是一个小问题。