parsing - 哪种 Haskell 解析技术最好用，为什么？

Question

关闭。这个问题是 opinion-based 。目前不接受答案。

---

想要改进这个问题吗？更新问题，以便 editing this post 可以用事实和引文来回答它。 .

已关闭 9 年前。

Improve this question

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

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

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

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

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

Answer 1

这实际上取决于您从什么开始以及您想要做什么。没有一刀切的方法。

如果有 LR 语法(例如，您正在使用 Yacc 语法)，则将其转换为适合 Parsec 或 uu-parsinglib 的 LL 语法是一项艰巨的工作。然而，many、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)，这意味着它更强大。展望。

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

根据记录，我用 Frown 编写了一个 C 解析器，用 Happy 编写了 GL 着色语言，用 UU_Parsing 编写了一个未完成的 C 解析器，以及用 Parsec 编写了许多东西。我的选择是我开始时的 LR 语法 - Frown 或 Happy(现在 Happy 因为 Frown 不再维护)，否则通常是 Parsec(正如我所说的 uu_parse 很好，但缺乏 LanguageDef 的便利)。对于二进制格式，我自己设计，但通常有特殊要求。