LRSTAR: LR(*) parser generator for C++


Home Downloads Feedback Comparison Theoretical Documentation Contact

LRSTAR vs ANTLR vs Bison

LL(1) Parsers (recursive descent) yes
LL(*) Look-Ahead Algorithm yes
LALR(1) Parsers yes
Canonical LR(1) Parsers yes
Minimal LR(1) Parsers yes IELR
LR(*) Look-Ahead Algorithm yes
GLR Parsers yes
EBNF grammar notation (?,+,*) yes yes
Grammar is independent from code yes yes
Reports conflicts in your grammar yes yes
Symbol-Table Builder yes yes
AST Construction & Traversal yes parse tree
C++ Output yes yes yes
C# Output yes
Java Output yes yes

LL(*) parsers

It's a clever soluiton for ambiguous grammars, but you may find that performance is not at a high level and you may never know that your grammar is ambiguous.

LALR(1) parsers

LALR(1) parsers were the favorite type of LR parser for many years, but now LR(1) is a better choice. LALR(1) analysis sometimes reports mysterious conflicts in your grammar, which are hard to understand. LR(1) analysis may resolve some conflicts that LALR(1) cannot resolve.

Canonical LR(1) parsers

They are interesting to study in the academic world and work fine for small and medium size languages, but for large and complex languages, MLR or LR(*) may be necessary.

Minimal LR(1) parsers

Minimal LR(1) parsers are "optimized" Canonical LR(1) parsers, optimized by reducing the size by a huge amount. In fact, for the DB2 language, the CLR(1) parser table is 50 MB, where as the MLR(1) parser table is only 160 K. The parser generation time is also dramatically reduced by creating MLR(1) parsers. Finally, the parsing speed of MLR(1) parsers is about 25% faster than CLR(1) parsers.

GLR parsers

GLR parsers are useful in the real world, but you may find that they are using a lot of memory and a lot of time to resolve ambiguity.

Note:   Things change over time. Some of these items may be different from what is shown above. To make sure you have the latest information, visit the competitor's website

(c) Copyright LRTEC 2020.  All rights reserved.