|Help needed on LALR(1) ambiguity email@example.com (2008-11-14)|
|Re: Help needed on LALR(1) ambiguity firstname.lastname@example.org (Chris Dodd) (2008-11-17)|
|Re: Help needed on LALR(1) ambiguity email@example.com (Armel) (2008-11-17)|
|Re: Help needed on LALR(1) ambiguity firstname.lastname@example.org (Sven-Olof Nystrom) (2008-11-18)|
|Re: Help needed on LALR(1) ambiguity email@example.com (2008-11-18)|
|Re: Help needed on LALR(1) ambiguity Danny.Dube@ift.ulaval.ca (2008-12-01)|
|Date:||Mon, 17 Nov 2008 16:24:12 +0100|
|Organization:||les newsgroups par Orange|
|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
> 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.
Return to the
Search the comp.compilers archives again.