哪个Haskell解析技术最令人愉快地使用，为什么？

Question

“令人愉快”的含义，例如：您可以用“自然”方式编写文法，而不必以复杂的方式重写它们，而无需引入无聊的样板。

为了这个问题的目的，我们要规定，除非一种技术的性能不好，否则性能不是这里最大的问题。

尽管如此，您可能想提及一个技术是否因为性能原因而重写语法时出现故障。

当回答这个问题时，请给我一个关于您使用的语法的大小和复杂性的想法。此外，您是否使用过该技术的任何显着的“高级”功能，以及您对这些技术的印象如何。

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

Answer 1

这真的取决于你开始和想要做什么。没有一个适合所有人的。

如果有一个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.一个语法。编程语言有复杂的语法，但你可以期望相当小的文件。至于数据文件格式，格式设计者真的应该以这样的方式来设计它，以便高效地解析。对于combinator解析器，你不应该为数据格式文件需要许多高级功能 - 如果你这样做，或者格式设计的很糟糕（这有时会不幸发生），或者你的解析器是。

为了记录我写了一个带有Frown的C语法分析器，带有Happy的GL-shading语言，带有UU_Parsing的未完成的C语法分析器，以及许多Parsec的事情。对于我来说，我选择的是LR语法--Frown或Happy（现在不用维护Frown），否则通常是Parsec（正如我所说的uu_parse很好，但缺乏LanguageDef的便利）。对于二进制格式我自己推出，但我通常有特殊要求。

Answer 2

我们使用'uu-parsinglib'获得了巨大成功 - 我们已经从Parsec转换到了它，因为它更加灵活和强大 - 例如，如果需要它可以支持懒惰分析，而且您不需要明确使用一个组合器（如Parsec中的'try'）来标记可能的回溯点。

确实，目前您需要在事物的标记化方面多做一些工作，但对于我们来说，这与图书馆的基本优势相比是一个小点。

Answer 3

最近，我在uu-parsinglib中重写了一个已经写在parsec中的DSL解析器。我发现它大大简化了程序。我的主要动机是获得自动更正方面。这只是起作用。它几乎免费！另外，我更喜欢以适用的风格写作我的解析器，而不是Parsec的monadic风格。