Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| 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: | "Armel" <armelasselin@hotmail.com> |
| Newsgroups: | comp.compilers |
| Date: | Mon, 17 Nov 2008 16:24:12 +0100 |
| Organization: | les newsgroups par Orange |
| References: | 08-11-055 08-11-075 |
| Keywords: | LALR, parse |
| Posted-Date: | 17 Nov 2008 18:29:15 EST |
> 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.
That's just MHO but for the untrained eye, it also means that the language
is almost incomprehensible... large expressions cannot be understood without
reading all the epxression(!?).
If the OP is still designing the language i'm pretty sure that it would be
great idea to find another, still elegant, way to write the same thing and
avoid the conflict by design... generators which find conflicts are indeed
good indicators of situations which were overseen by the designer but will
certainely loose the actual programmer.
HIH
Armel
Return to the
comp.compilers page.
Search the
comp.compilers archives again.