Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| Related articles |
|---|
| Backtracking yacc jarmo@ksvltd.FI (Jarmo Raiha) (1992-09-10) |
| Re: Backtracking yacc ipser@solomon.technet.sg (1992-09-11) |
| Re: Backtracking yacc sasghm@unx.sas.com (Gary Merrill) (1992-09-11) |
| Re: Backtracking yacc sasghm@unx.sas.com (Gary Merrill) (1992-09-14) |
| Re: Backtracking yacc ipser@solomon.technet.sg (1992-09-16) |
| Re: Backtracking yacc bromage@mullauna.cs.mu.OZ.AU (1992-09-17) |
| Re: Backtracking yacc Jasper.Kamperman@cwi.nl (1992-09-17) |
| [14 later articles] |
| Newsgroups: | comp.compilers |
| From: | Jarmo Raiha <jarmo@ksvltd.FI> |
| Organization: | Compilers Central |
| Date: | Thu, 10 Sep 1992 23:01:10 GMT |
| Keywords: | yacc, parse, question, comment |
Has anybody seen such a thing as backtracking yacc? What I had in mind
was a LALR parser that resolves ambiquity by backtracking to the point
where it had multiple routes to go. It would parse the input until it
encounters a dead end, and after that it would try an alternative path.
I know this would not solve much. Resolving the the conflicts 'the wrong
way' can still result to an errorless parsing, but I would like to know if
there have been any study about this approach. Is this a completely dead
idea ?
Jarmo Raiha
[That might help for conflicts in an unambiguous grammar that needs more than
one token lookahead, but not for the more common case that a conflict is due
to a truly ambiguous grammar. Besides, isn't there a theorem that says that
any LR(k) grammar can be rewritten as LR(1)? -John]
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.