| ast 1 AST construction in parser
Abstract-Syntax Tree construction. With this option set to 1, any
+> or *> action operators
in your grammar will cause the generated parser to build an AST.
In some cases you might want to disable the AST construction for debugging or
creating a syntax checker only. So, just set ast=0.
| k 1 k-lookaheads for LR(*) parsing
With k=1, you will get a classical LALR(1) parser. Any "shift-reduce" conflicts
will be resolved by choosing the "shift" action. Any "reduce-reduce" conflicts
will be resolved by choosing the rule which was first seen in the grammar.
k=2 or more
With k=2 or more, you don't have to worry about conflicts in your grammar and the
LR(*) parsing algorithm will take care of everything. If /k=5 or more does not parse
your language, then there is probably some ambiguity in your grammar. Looking at the
conflict reports should help you find the problem.
LALR(1) used to handle "most" programming languages, when someone could beat the grammar
into LALR compliance. But language designers don't care about compiler writers and compiler
writers have moved away from grammars and prefer hand-coded resursive-descent methods.
LR(*) is the solution. LR(2) or LR(3) gets to the place of handing 99% of programming
languages, WITHOUT having to beat your grammar into LALR compliance. If /o=5 cannot handle
your language, then your grammar needs to be rethunk, or your language has a poor design.
The LR(*) parser algorithm has reasonable limitations. It does not allow calling
any actions while in operation. Neither does it allow recursively calling itself. If you need
a more sophisticated LR(*) parser, maybe it's because your grammar has real ambiguities in it or
your language is so complex that you will have to write some special parse-action functions.
| m 0 Minimize parser-table size.
This may give a decrease in size of the parser tables by 10% or more.
| o 0 Optimize parser-table speed.
This does chain-reduction elimination in the states.