Related articles |
---|
Help needed on LALR(1) ambiguity philip.k.chow@gmail.com (2008-11-14) |
Re: Help needed on LALR(1) ambiguity cdodd@acm.org (Chris Dodd) (2008-11-17) |
Re: Help needed on LALR(1) ambiguity armelasselin@hotmail.com (Armel) (2008-11-17) |
Re: Help needed on LALR(1) ambiguity svenolof.nystrom-nospam@bredband.net (Sven-Olof Nystrom) (2008-11-18) |
Re: Help needed on LALR(1) ambiguity philip.k.chow@gmail.com (2008-11-18) |
Re: Help needed on LALR(1) ambiguity Danny.Dube@ift.ulaval.ca (2008-12-01) |
From: | Chris Dodd <cdodd@acm.org> |
Newsgroups: | comp.compilers |
Date: | Mon, 17 Nov 2008 00:25:38 -0600 |
Organization: | Compilers Central |
References: | 08-11-055 |
Keywords: | parse, theory |
Posted-Date: | 17 Nov 2008 08:25:16 EST |
philip.k.chow@gmail.com wrote in news:08-11-055@comp.compilers:
(grammar deleted)
> Here is a tricky sentence that demonstrates why it's hard:
>
> all a: all b, c: all d | x
>
> This has only one legal parse (parentheses added for clarification):
>
> all (a:all b), (c:all d) | x
To understand precisely why this is so hard, consider what happens if you
add a |-suffix to the end:
all a: all b, c: all d | x | y
now the parse looks completely different:
all (a: all (b, c : all d) | x) | y
So the problem is that you need to be able to look ahead to the end of the
input to see how many |-suffixes there are in order to figure out how to
parse the beginning of the expression. This makes it pretty much impossible
to parse without unbounded lookahead, or backtracking, or something else.
Chris Dodd
cdodd@acm.org
Return to the
comp.compilers page.
Search the
comp.compilers archives again.