适用于yacc/byacc/bison和lex/flex

Question

我读到的与这些实用程序有关的大多数帖子通常都建议使用其他方法来获得相同的效果.例如,通常提到这些工具的问题至少有一个答案包含以下一些内容:

• 使用boost库(在此插入适当的boost库)
• 不要创建DSL使用(在这里插入喜欢的脚本语言)
• Antlr更好

---

假设开发人员......

• ...对C语言感到满意
• ...确实知道至少一种脚本语言(例如,Python,Perl等)
• ...必须在几乎所有项目中编写一些解析代码

---

所以我的问题是:

• 什么是适合这些公用事业的适当情况？
• 是否存在任何(合理的)情况,除了yacc和lex(或衍生物)之外没有比问题更好的替代方案？
• 在实际的解析问题中,有多少人会期望遇到yacc和lex中的任何缺点,这些缺点可以通过更新的解决方案得到更好的解决？
• 对于那些还不熟悉这些工具的开发人员来说,花时间学习他们的语法/习语是值得的吗？这些与其他解决方案相比如何？

Answer 1

lex/yacc和衍生品在今天如此普遍存在的原因是它们比其他工具存在的时间长得多,它们在文献中有更多的覆盖范围,而且传统上它们都带有Unix操作系统.它与其他词法分析器和解析器生成器工具的比较几乎没有什么关系.

无论您选择哪种工具,总会有一个重要的学习曲线.因此,一旦您使用了一个给定的工具并且在使用中变得相对舒适,您就不太可能想要学习另一个工具的额外工作.那是很自然的.

此外,在20世纪60年代末和70年代早期创建lex/yacc时,硬件限制对解析提出了严峻挑战.Yacc使用的表驱动LR解析方法当时是最合适的,因为它可以通过使用相对较小的通用程序逻辑并将状态保持在磁带或磁盘上的文件中来实现,占用内存较少.诸如LL之类的代码驱动的解析方法具有更大的最小内存占用,因为解析器程序的代码本身代表语法,因此它需要完全适合RAM来执行,并且它将状态保持在RAM中的堆栈上.

当内存变得越来越丰富时,更多的研究进入了不同的解析方法,如LL和PEG,以及如何使用这些方法构建工具.这意味着在lex/yacc系列之后创建的许多替代工具使用不同类型的语法.然而,切换语法类型也会产生重要的学习曲线.一旦熟悉了一种语法,例如LR或LALR语法,就不太可能想要切换到使用不同类型语法的工具,例如LL语法.

总体而言,lex/yacc系列工具通常比最近到来的工具更为简陋,这些工具通常具有复杂的用户界面,可以图形化地显示语法和语法冲突,甚至通过自动重构来解决冲突.

因此,如果您之前没有使用任何解析器工具的经验,那么无论如何您必须学习新工具,那么您应该考虑其他因素,例如语法和冲突的图形可视化,自动重构,良好文档的可用性,语言其中生成的词法分析器/解析器可以输出等等.不要选择任何工具只是因为"这是其他人似乎正在使用的".

以下是我可以想到使用lex/yacc或flex/bison的一些原因:

• 开发人员已经熟悉lex/yacc或flex/bison
• 开发人员对LR/LALR语法最熟悉和最熟悉
• 开发商有很多关于lex/yacc的书籍,但没有涵盖其他书籍的书籍
• 开发商有一个未来的工作机会,并被告知lex/yacc技能将增加他获得雇用的机会
• 开发商无法从项目成员/利益相关者那里获得使用其他工具的支持
• 环境安装了lex/yacc,由于某种原因,安装其他工具是不可行的