412 |
@cindex generalized @acronym{LR} (@acronym{GLR}) parsing |
@cindex generalized @acronym{LR} (@acronym{GLR}) parsing |
413 |
@cindex ambiguous grammars |
@cindex ambiguous grammars |
414 |
@cindex non-deterministic parsing |
@cindex non-deterministic parsing |
415 |
Parsers for @acronym{LALR}(1) grammars are @dfn{deterministic}, |
|
416 |
meaning roughly that |
Parsers for @acronym{LALR}(1) grammars are @dfn{deterministic}, meaning |
417 |
the next grammar rule to apply at any point in the input is uniquely |
roughly that the next grammar rule to apply at any point in the input is |
418 |
determined by the preceding input and a fixed, finite portion (called |
uniquely determined by the preceding input and a fixed, finite portion |
419 |
a @dfn{look-ahead}) of the remaining input. |
(called a @dfn{look-ahead}) of the remaining input. A context-free |
420 |
A context-free grammar can be @dfn{ambiguous}, meaning that |
grammar can be @dfn{ambiguous}, meaning that there are multiple ways to |
421 |
there are multiple ways to apply the grammar rules to get the some inputs. |
apply the grammar rules to get the some inputs. Even unambiguous |
422 |
Even unambiguous grammars can be @dfn{non-deterministic}, meaning that no |
grammars can be @dfn{non-deterministic}, meaning that no fixed |
423 |
fixed look-ahead always suffices to determine the next grammar rule to apply. |
look-ahead always suffices to determine the next grammar rule to apply. |
424 |
With the proper declarations, Bison is also able to parse these more general |
With the proper declarations, Bison is also able to parse these more |
425 |
context-free grammars, using a technique known as @acronym{GLR} parsing (for |
general context-free grammars, using a technique known as @acronym{GLR} |
426 |
Generalized @acronym{LR}). Bison's @acronym{GLR} parsers are able to |
parsing (for Generalized @acronym{LR}). Bison's @acronym{GLR} parsers |
427 |
handle any context-free |
are able to handle any context-free grammar for which the number of |
428 |
grammar for which the number of possible parses of any given string |
possible parses of any given string is finite. |
|
is finite. |
|
429 |
|
|
430 |
@cindex symbols (abstract) |
@cindex symbols (abstract) |
431 |
@cindex token |
@cindex token |
432 |
@cindex syntactic grouping |
@cindex syntactic grouping |
433 |
@cindex grouping, syntactic |
@cindex grouping, syntactic |
434 |
In the formal grammatical rules for a language, each kind of syntactic unit |
In the formal grammatical rules for a language, each kind of syntactic |
435 |
or grouping is named by a @dfn{symbol}. Those which are built by grouping |
unit or grouping is named by a @dfn{symbol}. Those which are built by |
436 |
smaller constructs according to grammatical rules are called |
grouping smaller constructs according to grammatical rules are called |
437 |
@dfn{nonterminal symbols}; those which can't be subdivided are called |
@dfn{nonterminal symbols}; those which can't be subdivided are called |
438 |
@dfn{terminal symbols} or @dfn{token types}. We call a piece of input |
@dfn{terminal symbols} or @dfn{token types}. We call a piece of input |
439 |
corresponding to a single terminal symbol a @dfn{token}, and a piece |
corresponding to a single terminal symbol a @dfn{token}, and a piece |
440 |
corresponding to a single nonterminal symbol a @dfn{grouping}. |
corresponding to a single nonterminal symbol a @dfn{grouping}. |
441 |
|
|
442 |
We can use the C language as an example of what symbols, terminal and |
We can use the C language as an example of what symbols, terminal and |
443 |
nonterminal, mean. The tokens of C are identifiers, constants (numeric and |
nonterminal, mean. The tokens of C are identifiers, constants (numeric |
444 |
string), and the various keywords, arithmetic operators and punctuation |
and string), and the various keywords, arithmetic operators and |
445 |
marks. So the terminal symbols of a grammar for C include `identifier', |
punctuation marks. So the terminal symbols of a grammar for C include |
446 |
`number', `string', plus one symbol for each keyword, operator or |
`identifier', `number', `string', plus one symbol for each keyword, |
447 |
punctuation mark: `if', `return', `const', `static', `int', `char', |
operator or punctuation mark: `if', `return', `const', `static', `int', |
448 |
`plus-sign', `open-brace', `close-brace', `comma' and many more. (These |
`char', `plus-sign', `open-brace', `close-brace', `comma' and many more. |
449 |
tokens can be subdivided into characters, but that is a matter of |
(These tokens can be subdivided into characters, but that is a matter of |
450 |
lexicography, not grammar.) |
lexicography, not grammar.) |
451 |
|
|
452 |
Here is a simple C function subdivided into tokens: |
Here is a simple C function subdivided into tokens: |
641 |
@cindex conflicts |
@cindex conflicts |
642 |
@cindex shift/reduce conflicts |
@cindex shift/reduce conflicts |
643 |
|
|
644 |
In some grammars, there will be cases where Bison's standard @acronym{LALR}(1) |
In some grammars, there will be cases where Bison's standard |
645 |
parsing algorithm cannot decide whether to apply a certain grammar rule |
@acronym{LALR}(1) parsing algorithm cannot decide whether to apply a |
646 |
at a given point. That is, it may not be able to decide (on the basis |
certain grammar rule at a given point. That is, it may not be able to |
647 |
of the input read so far) which of two possible reductions (applications |
decide (on the basis of the input read so far) which of two possible |
648 |
of a grammar rule) applies, or whether to apply a reduction or read more |
reductions (applications of a grammar rule) applies, or whether to apply |
649 |
of the input and apply a reduction later in the input. These are known |
a reduction or read more of the input and apply a reduction later in the |
650 |
respectively as @dfn{reduce/reduce} conflicts (@pxref{Reduce/Reduce}), |
input. These are known respectively as @dfn{reduce/reduce} conflicts |
651 |
and @dfn{shift/reduce} conflicts (@pxref{Shift/Reduce}). |
(@pxref{Reduce/Reduce}), and @dfn{shift/reduce} conflicts |
652 |
|
(@pxref{Shift/Reduce}). |
653 |
|
|
654 |
To use a grammar that is not easily modified to be @acronym{LALR}(1), a more |
To use a grammar that is not easily modified to be @acronym{LALR}(1), a |
655 |
general parsing algorithm is sometimes necessary. If you include |
more general parsing algorithm is sometimes necessary. If you include |
656 |
@code{%glr-parser} among the Bison declarations in your file |
@code{%glr-parser} among the Bison declarations in your file |
657 |
(@pxref{Grammar Outline}), the result will be a Generalized |
(@pxref{Grammar Outline}), the result will be a Generalized @acronym{LR} |
658 |
@acronym{LR} (@acronym{GLR}) |
(@acronym{GLR}) parser. These parsers handle Bison grammars that |
659 |
parser. These parsers handle Bison grammars that contain no unresolved |
contain no unresolved conflicts (i.e., after applying precedence |
660 |
conflicts (i.e., after applying precedence declarations) identically to |
declarations) identically to @acronym{LALR}(1) parsers. However, when |
661 |
@acronym{LALR}(1) parsers. However, when faced with unresolved |
faced with unresolved shift/reduce and reduce/reduce conflicts, |
662 |
shift/reduce and reduce/reduce conflicts, @acronym{GLR} parsers use |
@acronym{GLR} parsers use the simple expedient of doing both, |
663 |
the simple expedient of doing |
effectively cloning the parser to follow both possibilities. Each of |
664 |
both, effectively cloning the parser to follow both possibilities. Each |
the resulting parsers can again split, so that at any given time, there |
665 |
of the resulting parsers can again split, so that at any given time, |
can be any number of possible parses being explored. The parsers |
|
there can be any number of possible parses being explored. The parsers |
|
666 |
proceed in lockstep; that is, all of them consume (shift) a given input |
proceed in lockstep; that is, all of them consume (shift) a given input |
667 |
symbol before any of them proceed to the next. Each of the cloned |
symbol before any of them proceed to the next. Each of the cloned |
668 |
parsers eventually meets one of two possible fates: either it runs into |
parsers eventually meets one of two possible fates: either it runs into |
809 |
"x" y z + T <init-declare> x T <cast> y z + = <OR> |
"x" y z + T <init-declare> x T <cast> y z + = <OR> |
810 |
@end example |
@end example |
811 |
|
|
812 |
|
@sp 1 |
813 |
|
|
814 |
|
@cindex @code{incline} |
815 |
|
@cindex @acronym{GLR} parsers and @code{inline} |
816 |
|
Note that the @acronym{GLR} parsers require an ISO C89 compiler. In |
817 |
|
addition, they use the @code{inline} keyword, which is not C89, but a |
818 |
|
common extension. It is up to the user of these parsers to handle |
819 |
|
portability issues. For instance, if using Autoconf and the Autoconf |
820 |
|
macro @code{AC_C_INLINE}, a mere |
821 |
|
|
822 |
|
@example |
823 |
|
%@{ |
824 |
|
#include <config.h> |
825 |
|
%@} |
826 |
|
@end example |
827 |
|
|
828 |
|
@noindent |
829 |
|
will suffice. Otherwise, we suggest |
830 |
|
|
831 |
|
@example |
832 |
|
%@{ |
833 |
|
#if ! defined __GNUC__ && ! defined inline |
834 |
|
# define inline |
835 |
|
#endif |
836 |
|
%@} |
837 |
|
@end example |
838 |
|
|
839 |
@node Locations Overview |
@node Locations Overview |
840 |
@section Locations |
@section Locations |