/[bison]/bison/doc/bison.texinfo
ViewVC logotype

Diff of /bison/doc/bison.texinfo

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.81 by akim, Thu Nov 14 08:32:10 2002 UTC revision 1.82 by akim, Thu Nov 14 09:58:01 2002 UTC
# Line 412  more information on this. Line 412  more information on this.
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:
# Line 642  from the values of the two subexpression Line 641  from the values of the two subexpression
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
# Line 810  as both an @code{expr} and a @code{decl} Line 809  as both an @code{expr} and a @code{decl}
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

Legend:
Removed from v.1.81  
changed lines
  Added in v.1.82

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26