柠檬的力量与否？

有趣的发现！我实际上并没有使用它，所以评论是基于阅读文档。 重新设计使得词法分析与解析分开进行，这似乎是有价值的。特别是，它有可能简化操作，例如处理多个或嵌套的源文件。基于Lex的

yywrap()

机制不太理想。它避免了所有全局变量，并且仔细考虑内存分配和释放控制应该有利于它（它允许分配器和解除分配器的选择也极大地帮助 - 至少对于我工作的环境，内存分配总是一个问题） 。 重新思考如何组织规则以及如何识别终端是一个好主意。 总而言之，它看起来像是经过深思熟虑的Bison重新设计。 根据引用的网页，它在公共领域。     

我们在固件项目中使用Lemon的原因是： 生成的代码和内存占用空间很小。它产生了我发现的最小的解析器（我比较了flex，bison，ANTLR和Lemon生成的类似复杂度的解析器）; 嵌入式系统的出色支持：Lemon不依赖于标准库，可以指定外部存储器管理功能，可以移除调试日志。 公共领域许可证。根据GPLv2许可的单独的Lemon分叉因病毒许可而不适合我们的需求。所以我们得到最新的sqlite源代码并从中编译Lemon（它只包含两个文件）; 拉解析。它使代码比Flex / Bison解析代码更容易理解和维护。线程安全作为我佩服的额外奖励。 与tokenizer的简单集成。我们的项目性质需要使用可变标记大小来标记二进制流。这是一个非常容易实现的标记化器，并且只与3个函数和一个反馈上下文变量的解析器API集成。我们研究了将Lemon与re2c和Ragel集成的方法，并发现它们也很容易实现。 非常简单的语法快速学习。 Lemon明确地将tokenizer和词法分析器（解析器）的开发分开。我的开发流程从设计解析器语法开始。我可以通过在第一阶段的几个Parser（...）调用来检查具有隐式令牌序列的复杂规则。之后实现Tokenizer。 当然柠檬不是银弹，它的应用范围有限。缺点包括： 与Bison相比，Lemon需要编写更多规则，因为语法简化：没有重复和选项，每个规则一个动作等。 完整的LALR（1）解析器限制集。 只有C语言。 在做出选择之前，权衡利弊。我做了我的;-)