Re: LR Grammars not in LALR(1) or LR(1)

"Clint Olsen" <clint@0lsen.net>
13 Oct 2002 16:01:50 -0400

          From comp.compilers

Related articles
[9 earlier articles]
Re: LR Grammars not in LALR(1) or LR(1) haberg@matematik.su.se (Hans Aberg) (2002-09-22)
Re: LR Grammars not in LALR(1) or LR(1) thp@cs.ucr.edu (2002-09-25)
Re: LR Grammars not in LALR(1) or LR(1) Mark.van.den.Brand@cwi.nl (M.G.J. van den Brand) (2002-09-25)
Re: LR Grammars not in LALR(1) or LR(1) Mark.van.den.Brand@cwi.nl (M.G.J. van den Brand) (2002-09-29)
Re: LR Grammars not in LALR(1) or LR(1) haberg@matematik.su.se (Hans Aberg) (2002-09-29)
Re: LR Grammars not in LALR(1) or LR(1) joachim_d@gmx.de (Joachim Durchholz) (2002-09-29)
Re: LR Grammars not in LALR(1) or LR(1) clint@0lsen.net (Clint Olsen) (2002-10-13)
Re: LR Grammars not in LALR(1) or LR(1) cfc@shell01.TheWorld.com (Chris F Clark) (2002-10-13)
Re: LR Grammars not in LALR(1) or LR(1) Mark.van.den.Brand@cwi.nl (M.G.J. van den Brand) (2002-10-13)
Re: LR Grammars not in LALR(1) or LR(1) ska1@snafu.de (Sönke Kannapinn) (2002-10-18)
Re: LR Grammars not in LALR(1) or LR(1) joachim_d@gmx.de (Joachim Durchholz) (2002-10-20)
Re: LR Grammars not in LALR(1) or LR(1) clint@0lsen.net (Clint Olsen) (2002-10-24)
Re: LR Grammars not in LALR(1) or LR(1) ska1@snafu.de (Sönke Kannapinn) (2002-10-25)
| List of all articles for this month |
From: "Clint Olsen" <clint@0lsen.net>
Newsgroups: comp.compilers
Date: 13 Oct 2002 16:01:50 -0400
Organization: AT&T Broadband
References: 02-09-014 02-09-029 02-09-068 02-09-092 02-09-097 02-09-126 02-09-130 02-09-143 02-09-161
Keywords: parse, yacc
Posted-Date: 13 Oct 2002 16:01:50 EDT

John Levine [moderator] wrote:
> [Bison is actually a descendant of Berkeley Yacc, but unless something
> has changed radically, they both use the same table generating and
> parsing algorithms. -John]


If you download the alpha version of bison (1.49a), they've actually
added GLR parsing support. In the event of an ambiguity, bison
replicates itself down both parse branches and then either kills off
the exploration because of a parse error or merges them if they reduce
to the same thing. This continues apparently down every ambiguous
branch respectively.


-Clint


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.