@end group
%%
-
-@group
type_decl: TYPE ID '=' type ';' ;
-@end group
@group
type:
@comment file: rpcalc.y
@example
-@group
#include <stdio.h>
-@end group
@group
/* Called by yyparse on error. */
@comment file: mfcalc.y: 3
@example
-@group
#include <ctype.h>
-@end group
@group
int
A Bison grammar rule has the following general form:
@example
-@group
@var{result}: @var{components}@dots{};
-@end group
@end example
@noindent
For example,
@example
-@group
exp: exp '+' exp;
-@end group
@end example
@noindent
following example, the action is triggered only when @samp{b} is found:
@example
-@group
a-or-b: 'a'|'b' @{ a_or_b_found = 1; @};
-@end group
@end example
@cindex default action
the conflict:
@example
-@group
%%
-@end group
@group
stmt:
expr
@example
@group
-%nonassoc "then"
-%nonassoc "else"
+%precedence "then"
+%precedence "else"
@end group
@end example
@end example
Neither solution is perfect however. Since Bison does not provide, so far,
-support for ``scoped'' precedence, both force you to declare the precedence
+``scoped'' precedence, both force you to declare the precedence
of these keywords with respect to the other operators your grammar.
Therefore, instead of being warned about new conflicts you would be unaware
of (e.g., a shift/reduce conflict due to @samp{if test then 1 else 2 + 3}
Here is another common error that yields a reduce/reduce conflict:
@example
-sequence:
@group
+sequence:
/* empty */
| sequence words
| sequence redirects
rule:
@example
-%nonassoc "word"
-%nonassoc "sequence"
+%precedence "word"
+%precedence "sequence"
%%
@group
sequence:
| name_list ':' type
;
@end group
+
@group
return_spec:
type
| name ':' type
;
@end group
-@group
+
type: "id";
-@end group
+
@group
name: "id";
name_list:
rather than the one for @code{name}.
@example
+@group
param_spec:
type
| name_list ':' type
;
+@end group
+
+@group
return_spec:
type
| "id" ':' type
;
+@end group
@end example
For a more detailed exposition of LALR(1) parsers and parser
@cindex GLR with LALR
When employing GLR parsers (@pxref{GLR Parsers}), if you do not resolve any
-conflicts statically (for example, with @code{%left} or @code{%prec}), then
+conflicts statically (for example, with @code{%left} or @code{%precedence}),
+then
the parser explores all potential parses of any given input. In this case,
the choice of parser table construction algorithm is guaranteed not to alter
the language accepted by the parser. LALR parser tables are the smallest