柠檬的力量与否?

Ste*_*tef 18 c parsing bison parser-generator lemon

对于语法分析器,我曾经与Bison "玩",它有其优点/缺点.

上周,我在SqLite网站上注意到该引擎已经完成了另一个语法分析器: Lemon

阅读精简文档后听起来很棒.
你有关于这个解析器的一些反馈吗?

无法真正看到谷歌和维基百科上的相关信息(只是一些例子,相同的教程)它似乎不太受欢迎.(Stack Overflow中没有标签[编辑:现在有:P])

Art*_*ich 19

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

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

当然柠檬不是银弹,它的应用范围有限.缺点包括:

  • 与Bison相比,Lemon需要编写更多规则,因为语法简化:没有重复和选项,每个规则一个动作等.
  • 完整的LALR(1)解析器限制集.
  • 只有C语言.

在做出选择之前权衡利弊.我做了我的;-)

  • 用C语言编写可能"有时"被视为真正的优势! (5认同)

Jon*_*ler 6

有趣的发现!我实际上没有使用它,所以评论是基于阅读文档.

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

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

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

根据引用的网页,它在公共领域.