"愉快"的含义,例如:你可以以"自然"的方式编写语法而不必以复杂的方式重写它们,而不必引入枯燥的样板.
让我们为这个问题的目的规定,除非技术性能在病理上是坏的,否则性能不是最重要的问题.
尽管如此,你可能想提一下,当出于性能原因而不得不重写语法时,技术是否会失败.
在回答这个问题时,请让我了解你曾经使用的语法的大小和复杂性.此外,您是否使用了相关技术的任何值得注意的"高级"功能,以及您对这些功能的印象.
当然,这个问题的答案可能取决于领域,在这种情况下,我很乐意了解这一事实.
ste*_*ley 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),这意味着它更具有前瞻性.
对于语法来说,性能并不是一个很大的问题.编程语言有复杂的语法,但你可以期待相当小的文件.至于数据文件格式,格式的设计者真的应该以这样的方式设计它,以便它允许有效的解析.对于组合器解析器,您不需要为数据格式文件提供许多高级功能 - 如果这样做,要么格式设计不当(有时会发生这种情况)或者您的解析器是.
为了记录,我编写了一个带有Frown的GL解析器,带有Happy的GL着色语言,一个带有UU_Parsing的未完成的C语法分析器,以及Parsec的很多东西.对我的选择是我的开始,LR语法 - 皱眉或快乐(现在没有保持快乐皱眉),否则通常是Parsec(因为我说uu_parse很好但缺乏LanguageDef的便利).对于二进制格式,我自己动手,但我通常有特殊要求.
小智 5
我们使用'uu-parsinglib'取得了巨大成功 - 我们已经从Parsec切换到了它,因为它更加灵活和强大 - 例如,如果需要它可以支持延迟解析,而且你不需要明确地使用组合器(如Parsec中的'try')标记可能的反向跟踪点.
确实,目前你需要在事物的标记化方面做更多的事情,但对于我们来说,相对于图书馆的基本优势而言,这是一个小点.
小智 5
最近,我在uu-parsinglib中重新编写了一个用parsec编写的DSL解析器.我发现它大大简化了程序.我的主要动机是获得自动纠正方面.这才有效.它实际上是免费的!此外,我更倾向于以应用风格编写我的解析器,而不是Parsec的monadic风格.