柠檬力还是不柠檬力？

Question

对于语法解析器，我曾经使用 Bison 来“玩”，它有它的优点/缺点。

上周，我在 SqLite 网站上注意到该引擎是用另一个语法解析器完成的：柠檬

读完薄文档后听起来很棒。
您对这个解析器有什么反馈吗？

无法真正在谷歌和维基百科上看到相关信息（只是一些例子，相同的教程）它似乎不是很受欢迎。 （Stack Overflow 中没有 lemon 标签 [ed ：现在有：P]）

Answer 1

我们在固件项目中使用 Lemon 的原因是：

• 生成的代码尺寸小且内存占用少。它产生了我发现的最小的解析器（我比较了由 flex、bison、ANTLR 和 Lemon 生成的类似复杂度的解析器）；
• 对嵌入式系统的出色支持：Lemon不依赖于标准库，可以指定外部内存管理函数，调试日志记录可移除。
• 公共领域许可证。有一个根据 GPLv2 许可的单独的 Lemon 分支，由于病毒许可的原因，不适合我们的需求。因此，我们获取最新的 sqlite 源代码并从中编译 Lemon（它仅包含两个文件）；
• 拉式解析。它使代码比 Flex/Bison 解析代码更容易理解和维护。线程安全是我欣赏的额外好处。
• 与标记器的简单集成。我们的项目性质需要对具有可变标记大小的二进制流进行标记。这是一个非常容易实现的分词器，并与只有 3 个函数和一个反馈上下文变量的解析器 API 集成。我们研究了将 Lemon 与 re2c 和 Ragel 集成的方法，发现它们也很容易实现。
• 语法非常简单，学习起来很快。
• Lemon明确地将分词器和词法分析器（解析器）分开开发。我的开发流程从解析器语法的设计开始。我可以在第一阶段通过多次 Parser(...) 调用来检查具有隐式标记序列的复杂规则。 Tokenizer是随后实现的。

当然，柠檬并不是灵丹妙药，它的应用范围有限。缺点是：

• 与 Bison 相比，Lemon 需要编写更多规则，因为语法简化：无重复和可选、每个规则一个操作等。
• 完整的 LALR(1) 解析器限制集。
• 只有C语言。

在做出选择之前权衡利弊。我已经完成了我的;-)

Answer 2

有趣的发现！我没有实际使用过，所以评论是基于阅读文档。

重新设计使词法分析与解析分开进行似乎是有优点的。特别是，它有可能简化操作，例如处理多个或嵌套源文件。基于 Lex 的 yywrap() 机制不太理想。它避免了所有全局变量，并且具有仔细的内存分配和释放控制，这应该对它有利（它允许选择分配器和释放器也有很大帮助 - 至少对于我工作的环境来说，内存分配始终是一个问题） 。

重新思考如何组织规则以及如何识别终端是一个好主意。

总而言之，它看起来像是 Bison 经过深思熟虑的重新设计。

根据引用的网页，它属于公共领域。