+@item Default Value: @code{pull}
+@end itemize
+
+@c ================================================== lr.default-reductions
+
+@item lr.default-reductions
+@cindex default reductions
+@findex %define lr.default-reductions
+@cindex delayed syntax errors
+@cindex syntax errors delayed
+@cindex LAC
+@findex %nonassoc
+
+@itemize @bullet
+@item Language(s): all
+
+@item Purpose: Specify the kind of states that are permitted to
+contain default reductions.
+That is, in such a state, Bison selects the reduction with the largest
+lookahead set to be the default parser action and then removes that
+lookahead set.
+(The ability to specify where default reductions should be used is
+experimental.
+More user feedback will help to stabilize it.)
+
+@item Accepted Values:
+@itemize
+@item @code{all}.
+This is the traditional Bison behavior. The main advantage is a
+significant decrease in the size of the parser tables. The
+disadvantage is that, when the generated parser encounters a
+syntactically unacceptable token, the parser might then perform
+unnecessary default reductions before it can detect the syntax error.
+Such delayed syntax error detection is usually inherent in LALR and
+IELR parser tables anyway due to LR state merging (@pxref{%define
+Summary,,lr.type}). Furthermore, the use of @code{%nonassoc} can
+contribute to delayed syntax error detection even in the case of
+canonical LR. As an experimental feature, delayed syntax error
+detection can be overcome in all cases by enabling LAC (@pxref{%define
+Summary,,parse.lac}, for details, including a discussion of the
+effects of delayed syntax error detection).
+
+@item @code{consistent}.
+@cindex consistent states
+A consistent state is a state that has only one possible action.
+If that action is a reduction, then the parser does not need to request
+a lookahead token from the scanner before performing that action.
+However, the parser recognizes the ability to ignore the lookahead token
+in this way only when such a reduction is encoded as a default
+reduction.
+Thus, if default reductions are permitted only in consistent states,
+then a canonical LR parser that does not employ
+@code{%nonassoc} detects a syntax error as soon as it @emph{needs} the
+syntactically unacceptable token from the scanner.
+
+@item @code{accepting}.
+@cindex accepting state
+In the accepting state, the default reduction is actually the accept
+action.
+In this case, a canonical LR parser that does not employ
+@code{%nonassoc} detects a syntax error as soon as it @emph{reaches} the
+syntactically unacceptable token in the input.
+That is, it does not perform any extra reductions.
+@end itemize
+
+@item Default Value:
+@itemize
+@item @code{accepting} if @code{lr.type} is @code{canonical-lr}.
+@item @code{all} otherwise.
+@end itemize
+@end itemize
+
+@c ============================================ lr.keep-unreachable-states
+
+@item lr.keep-unreachable-states
+@findex %define lr.keep-unreachable-states
+
+@itemize @bullet
+@item Language(s): all
+
+@item Purpose: Request that Bison allow unreachable parser states to
+remain in the parser tables.
+Bison considers a state to be unreachable if there exists no sequence of
+transitions from the start state to that state.
+A state can become unreachable during conflict resolution if Bison disables a
+shift action leading to it from a predecessor state.
+Keeping unreachable states is sometimes useful for analysis purposes, but they
+are useless in the generated parser.
+
+@item Accepted Values: Boolean
+
+@item Default Value: @code{false}
+
+@item Caveats:
+
+@itemize @bullet
+
+@item Unreachable states may contain conflicts and may use rules not used in
+any other state.
+Thus, keeping unreachable states may induce warnings that are irrelevant to
+your parser's behavior, and it may eliminate warnings that are relevant.
+Of course, the change in warnings may actually be relevant to a parser table
+analysis that wants to keep unreachable states, so this behavior will likely
+remain in future Bison releases.
+
+@item While Bison is able to remove unreachable states, it is not guaranteed to
+remove other kinds of useless states.
+Specifically, when Bison disables reduce actions during conflict resolution,
+some goto actions may become useless, and thus some additional states may
+become useless.
+If Bison were to compute which goto actions were useless and then disable those
+actions, it could identify such states as unreachable and then remove those
+states.
+However, Bison does not compute which goto actions are useless.
+@end itemize
+@end itemize
+
+@c ================================================== lr.type
+
+@item lr.type
+@findex %define lr.type
+@cindex LALR
+@cindex IELR
+@cindex LR
+
+@itemize @bullet
+@item Language(s): all
+
+@item Purpose: Specify the type of parser tables within the
+LR(1) family.
+(This feature is experimental.
+More user feedback will help to stabilize it.)
+
+@item Accepted Values:
+@itemize
+@item @code{lalr}.
+While Bison generates LALR parser tables by default for
+historical reasons, IELR or canonical LR is almost
+always preferable for deterministic parsers.
+The trouble is that LALR parser tables can suffer from
+mysterious conflicts and thus may not accept the full set of sentences
+that IELR and canonical LR accept.
+@xref{Mystery Conflicts}, for details.
+However, there are at least two scenarios where LALR may be
+worthwhile:
+@itemize
+@cindex GLR with LALR
+@item When employing GLR parsers (@pxref{GLR Parsers}), if you
+do not resolve any conflicts statically (for example, with @code{%left}
+or @code{%prec}), then the parser explores all potential parses of any
+given input.
+In this case, the use of LALR parser tables is guaranteed not
+to alter the language accepted by the parser.
+LALR parser tables are the smallest parser tables Bison can
+currently generate, so they may be preferable.
+Nevertheless, once you begin to resolve conflicts statically,
+GLR begins to behave more like a deterministic parser, and so
+IELR and canonical LR can be helpful to avoid
+LALR's mysterious behavior.
+
+@item Occasionally during development, an especially malformed grammar
+with a major recurring flaw may severely impede the IELR or
+canonical LR parser table generation algorithm.
+LALR can be a quick way to generate parser tables in order to
+investigate such problems while ignoring the more subtle differences
+from IELR and canonical LR.
+@end itemize
+
+@item @code{ielr}.
+IELR is a minimal LR algorithm.
+That is, given any grammar (LR or non-LR),
+IELR and canonical LR always accept exactly the same
+set of sentences.
+However, as for LALR, the number of parser states is often an
+order of magnitude less for IELR than for canonical
+LR.
+More importantly, because canonical LR's extra parser states
+may contain duplicate conflicts in the case of non-LR
+grammars, the number of conflicts for IELR is often an order
+of magnitude less as well.
+This can significantly reduce the complexity of developing of a grammar.
+
+@item @code{canonical-lr}.
+@cindex delayed syntax errors
+@cindex syntax errors delayed
+@cindex LAC
+@findex %nonassoc
+While inefficient, canonical LR parser tables can be an interesting
+means to explore a grammar because they have a property that IELR and
+LALR tables do not. That is, if @code{%nonassoc} is not used and
+default reductions are left disabled (@pxref{%define
+Summary,,lr.default-reductions}), then, for every left context of
+every canonical LR state, the set of tokens accepted by that state is
+guaranteed to be the exact set of tokens that is syntactically
+acceptable in that left context. It might then seem that an advantage
+of canonical LR parsers in production is that, under the above
+constraints, they are guaranteed to detect a syntax error as soon as
+possible without performing any unnecessary reductions. However, IELR
+parsers using LAC (@pxref{%define Summary,,parse.lac}) are also able
+to achieve this behavior without sacrificing @code{%nonassoc} or
+default reductions.
+@end itemize
+
+@item Default Value: @code{lalr}
projects / bison.git / blobdiff