|(long) conflict resolution in action table firstname.lastname@example.org (Tim Newsham) (2003-09-04)|
|Re: (long) conflict resolution in action table derkgwen@HotPOP.com (Derk Gwen) (2003-09-09)|
|Re: (long) conflict resolution in action table email@example.com (2003-09-09)|
|Re: (long) conflict resolution in action table firstname.lastname@example.org (Tim Newsham) (2003-09-09)|
|Re: (long) conflict resolution in action table email@example.com (Tim Newsham) (2003-09-14)|
|From:||Derk Gwen <derkgwen@HotPOP.com>|
|Date:||9 Sep 2003 22:56:44 -0400|
|Organization:||Quick STOP Groceries|
|Posted-Date:||09 Sep 2003 22:56:44 EDT|
# My question: Is there anyway to augment Visser's conflict resolution
# so that it can be more effective when resolving a subset of the
# conflicts that occur? For example, is there a method that could
# produce a parser for my simple expression grammar that only encountered
# a ambiguity when the "^" operator was present in an input sentance?
If you want LR(k), there are LR(k) parser generators available. Two
different schemes are available, one based on not expanding
nonterminals in lookahead strings until you need to examine the
lookahead, thus avoiding that combinatorial explosion for the LR(0)
subgrammar. If you use LR(k), you don't have to cope with brain dead
LALR of yacc or bison. If the language is deterministic, it has an
LR(k) grammar without shift-reduce or reduce-reduce conflicts.
If you want to use a precedence parser, the Aho and Ullman Theory of
Parsing discusses a number of different precedence parsing schemes.
Yacc is the Microsoft of parser generators. An inadequate tool, widely
used, that crowds out better tools, and condemns generations to make
elaborate workarounds of its shortcomings that don't exist in better
Derk Gwen http://derkgwen.250free.com/html/index.html
Return to the
Search the comp.compilers archives again.