blocks|key|1498490|text|更新/警告:此答案可能已过期！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1498491|1498492|一个主要区别是ANTLR生成LL(*)解析器，而YACC和Bison都生成LALR解析器。这对于许多应用程序来说是一个重要的区别，最明显的是运算符：|1498493|expr+::=+expr+'%2B'+expr
+++++++%7C+expr+'-'+expr
+++++++%7C+'('+expr+')'
+++++++%7C+NUM+;|code-block|syntax|javascript|1498494|ANTLR完全无法按原样处理此语法。要使用ANTLR+(或任何其他LL解析器生成器)，您需要将此语法转换为非左递归的语法。但是，Bison对这种形式的语法没有问题。您需要将'%2B‘和'-’声明为左结合运算符，但这并不是左递归的严格要求。一个更好的例子可能是调度：|1498495|expr+::=+expr+'.'+ID+'('+actuals+')'+;

actuals+::=+actuals+','+expr+%7C+expr+;|1498496|注意，expr和actuals规则都是左递归的。当涉及到代码生成时，这会产生一个更有效的AST，因为它避免了多个寄存器和不必要的溢出(向左的树可以折叠，而向右的树不能)。|offset|length|style|CODE|1498497|就个人喜好而言，我认为LALR语法更容易构建和调试。缺点是你必须处理一些隐蔽的错误，比如shift-reduce和(可怕的)+reduce-reduce。这些是Bison在生成解析器时捕获的错误，因此它不会影响最终用户体验，但它可以使开发过程更有趣。正是由于这个原因，ANTLR通常被认为比YACC/Bison更容易使用。|1498498|entityMap^0|0|0|0|0|0|0|3|4|8|7|0|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|C|3|D|5|6|7|Z|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|10|8|@]|9|@]|A|$H|I]]|$1|J|3|K|5|6|7|11|8|@]|9|@]|A|$]]|$1|L|3|M|5|G|7|12|8|@]|9|@]|A|$H|I]]|$1|N|3|O|5|6|7|13|8|@$P|14|Q|15|R|S]|$P|16|Q|17|R|S]]|9|@]|A|$]]|$1|T|3|U|5|6|7|18|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|19|8|@]|9|@]|A|$]]]|W|$]]

<h3>Update/warning: This answer may be out of date!</h3>
<hr />
One major difference is that ANTLR generates an LL(*) parser, whereas YACC and Bison both generate parsers that are LALR. This is an important distinction for a number of applications, the most obvious being operators:
<pre><code>expr ::= expr '+' expr
 | expr '-' expr
 | '(' expr ')'
 | NUM ;
</code></pre>
ANTLR is entirely incapable of handling this grammar as-is. To use ANTLR (or any other LL parser generator), you would need to convert this grammar to something that is not left-recursive. However, Bison has no problem with grammars of this form. You would need to declare '+' and '-' as left-associative operators, but that is not strictly required for left recursion. A better example might be dispatch:
<pre><code>expr ::= expr '.' ID '(' actuals ')' ;

actuals ::= actuals ',' expr | expr ;
</code></pre>
Notice that both the <code>expr</code> and the <code>actuals</code> rules are left-recursive. This produces a much more efficient AST when it comes time for code generation because it avoids the need for multiple registers and unnecessary spilling (a left-leaning tree can be collapsed whereas a right-leaning tree cannot).
In terms of personal taste, I think that LALR grammars are a lot easier to construct and debug. The downside is you have to deal with somewhat cryptic errors like shift-reduce and (the dreaded) reduce-reduce. These are errors that Bison catches when generating the parser, so it doesn't affect the end-user experience, but it can make the development process a bit more interesting. ANTLR is generally considered to be easier to use than YACC/Bison for precisely this reason.

blocks|key|1498533|text|ANTRL的另一个优势是您可以使用ANTLRWORKS，尽管我不能说这是一个严格的优势，因为其他生成器可能也有类似的工具。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1498534|entityMap|0|LINK|mutability|MUTABLE|url|http://www.antlr.org/works/index.html^0|H|A|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Another advantage of ANTRL is that you can use <a href="http://www.antlr.org/works/index.html" rel="noreferrer">ANTLRWORKS</a>, although I can't say that this is a strict advantage, as there may be similar tools for other generators as well.

blocks|key|1713670|text|YACC/Bison和ANTLR之间最重要的区别是这些工具可以处理的语法类型。YACC/Bison处理LALR语法，ANTLR处理LL语法。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1713671|通常，长期使用LALR语法的人会发现使用LL语法更加困难，反之亦然。这并不意味着语法或工具本身就更难使用。你觉得哪个工具更容易使用主要取决于你对语法类型的熟悉程度。|1713672|就优点而言，LALR语法在某些方面优于LL语法，而LL语法在其他方面优于LALR语法。|1713673|YACC/Bison生成表驱动的解析器，这意味着“处理逻辑”包含在解析器程序的数据中，而不是包含在解析器的代码中。结果是，即使是非常复杂的语言的解析器也有相对较小的代码占用空间。这在硬件非常有限的20世纪60年代和70年代更为重要。表驱动的解析器生成器可以追溯到这个时代，当时的主要需求是代码占用空间小。|1713674|ANTLR生成递归下降解析器，这意味着“处理逻辑”包含在解析器的代码中，因为语法的每个产生规则都由解析器代码中的一个函数表示。这样做的好处是，通过读取解析器的代码，可以更容易地理解解析器在做什么。此外，递归下降解析器通常比表驱动的解析器更快。然而，对于非常复杂的语言，代码占用的空间将会更大。这在20世纪60年代和70年代是一个问题。当时，由于硬件的限制，只有像Pascal这样的相对较小的语言是以这种方式实现的。|1713675|ANTLR生成的解析器通常在10.000行代码附近，甚至更多。手写递归下降解析器通常处于相同的水平。Wirth的Oberon编译器可能是最紧凑的，大约有4000行代码，包括代码生成，但Oberon是一种非常紧凑的语言，只有大约40条产生式规则。|1713676|正如有人已经指出的，ANTLR的一个很大的优势是图形集成开发工具，称为ANTLRworks。它是一个完整的语法和语言设计实验室。当你输入语法规则时，它会可视化你的语法规则，如果它发现任何冲突，它会以图形方式显示冲突是什么，以及是什么导致了冲突。它甚至可以自动重构和解决冲突，如左递归。一旦你有了一个无冲突的语法，你就可以让ANTLRworks解析你的语言的输入文件，为你构建一个解析树，并在集成开发环境中以图形的方式显示该树。这是一个非常大的优势，因为它可以为您节省大量的工作时间:您将在开始编码之前发现语言设计中的概念性错误！我还没有为LALR语法找到这样的工具，似乎没有这样的工具。|1713677|即使对于那些不想生成解析器而是手工编写解析器的人来说，ANTLRworks也是一个很棒的语言设计/原型开发工具。很可能是可用的最好的工具。不幸的是，如果您想要构建LALR解析器，这对您没有帮助。仅仅为了利用ANTLRworks而从LALR切换到LL可能是值得的，但对于一些人来说，切换语法类型可能是一种非常痛苦的经历。换句话说:+YMMV。|1713678|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|V|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|W|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|X|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|Y|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|Q|$]]

The most significant difference between YACC/Bison and ANTLR is the type of grammars these tools can process. YACC/Bison handle LALR grammars, ANTLR handles LL grammars.

Often, people who have worked with LALR grammars for a long time, will find working with LL grammars more difficult and vice versa. That does not mean that the grammars or tools are inherently more difficult to work with. Which tool you find easier to use will mostly come down to familiarity with the type of grammar.

As far as advantages go, there are aspects where LALR grammars have advantages over LL grammars and there are other aspects where LL grammars have advantages over LALR grammars. 

YACC/Bison generate table driven parsers, which means the "processing logic" is contained in the parser program's data, not so much in the parser's code. The pay off is that even a parser for a very complex language has a relatively small code footprint. This was more important in the 1960s and 1970s when hardware was very limited. Table driven parser generators go back to this era and small code footprint was a main requirement back then.

ANTLR generates recursive descent parsers, which means the "processing logic" is contained in the parser's code, as each production rule of the grammar is represented by a function in the parser's code. The pay off is that it is easier to understand what the parser is doing by reading its code. Also, recursive descent parsers are typically faster than table driven ones. However, for very complex languages, the code footprint will be larger. This was a problem in the 1960s and 1970s. Back then, only relatively small languages like Pascal for instance were implemented this way due to hardware limitations.

ANTLR generated parsers are typically in the vicinity of 10.000 lines of code and more. Handwritten recursive descent parsers are often in the same ballpark. Wirth's Oberon compiler is perhaps the most compact one with about 4000 lines of code including code generation, but Oberon is a very compact language with only about 40 production rules.

As somebody has pointed out already, a big plus for ANTLR is the graphical IDE tool, called ANTLRworks. It is a complete grammar and language design laboratory. It visualises your grammar rules as you type them and if it finds any conflicts it will show you graphically what the conflict is and what causes it. It can even automatically refactor and resolve conflicts such as left-recursion. Once you have a conflict free grammar, you can let ANTLRworks parse an input file of your language and build a parse tree and AST for you and show the tree graphically in the IDE. This is a very big advantage because it can save you many hours of work: You will find conceptual errors in your language design before you start coding! I have not found any such tool for LALR grammars, it seems there isn't any such tool.

Even to people who do not wish to generate their parsers but hand code them, ANTLRworks is a great tool for language design/prototyping. Quite possibly the best such tool available. Unfortunately, that doesn't help you if you want to build LALR parsers. Switching from LALR to LL simply to take advantage of ANTLRworks may well be worthwhile, but for some people, switching grammar types can be a very painful experience. In other words: YMMV.

I've used lex and yacc (more usually bison) in the past for various projects, usually translators (such as a subset of EDIF streamed into an EDA app). Additionally, I've had to support code based on lex/yacc grammars dating back decades. So I know my way around the tools, though I'm no expert.

I've seen positive comments about Antlr in various fora in the past, and I'm curious as to what I may be missing. So if you've used both, please tell me what's better or more advanced in Antlr. My current constraints are that I work in a C++ shop, and any product we ship will not include Java, so the resulting parsers would have to follow that rule.

Advantages of Antlr (versus say, lex/yacc/bison)

集成开发环境

原型开发

编译器

Java

我过去在各种项目中使用过lex和yacc (更常见的是bison)，通常是翻译器(例如，流到EDA应用程序中的EDIF的子集)。此外，我必须支持基于几十年前的lex/yacc语法的代码。所以我知道如何使用这些工具，尽管我不是专家。我在过去的各种论坛上看到过关于Antlr的正面评论，我很好奇我可能会错过什么。所以如果你用...

问Antlr的优势(与lex/yacc/bison相比)
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Antlr的优势(与lex/yacc/bison相比)EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Antlr的优势(与lex/yacc/bison相比)
EN