On Wed, 2 Jul 2014 08:36:26 -0700
"Richard H. McCullough" <[email protected]> wrote:

> After looking at y.output, I don't think shift/reduce conflicts are the 
> problem.
> I think mKR requires too much look ahead.
> 
> Is iyacc supposed to tell me that?

I have often run into problems with iyacc's limitation of 1 lookahead;
it will report reduce-reduce conflict(s) if you exceed it.
I have sometimes fixed problems by re-factoring my rules, adding more 
nonterminals.
Adding multiple rules with common prefixes is sometimes helpful.

One grammar I wrote gave over 2000 shift-reduce conflicts, 
but I have used it for over a decade without finding any inappropriate syntax 
errors.

IIRC, grammars that are irreducibly lookahead 2+,  or rarely full-LR(1)* 
grammars, 
will always give reduce-reduce errors, and any iyacc output will be useless.
  *iyacc does LALR(1), which is a subset of LR(1). 
   Bison can optionally do LR(1) if lr.type is set, so check for lr.type in the 
grammar.
   Bison can do a GLR parser, so check for %glr-parser in your grammar. 
If you have no reduce-reduce errors but get incorrect results:
I don't know if iyacc cares about the order of rules or not.
If it does, you may need to re-order your rules or a rule's branches.
For untested grammars, remember that the order of your nonterminals is critical.
 
> Can I cure that by putting actions in the middle of rules?

I am not sure what you mean here. 
Factoring similar runs of similar terminals in the middle of rules to new 
nonterminals 
lets you put actions on a terminal phrase, and this often helps. 
One often ends up with fewer total rules as well.
I avoid mixing rules or terminals with different precedences when factoring. 
unigram.y has many examples for one to review.
If you can find examples of rules that are NOT LL(k), study them.

What we both need is a bounded-backtracking parser that can handle LR(2+) and 
produce icon code.
The alternative is writing workarounds that are AFAIK more art than science.
For this, classroom work that includes hand-compiling LR(1) grammars is very 
helpful. 

-- 
Charles Evans <[email protected]>

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Unicon-group mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/unicon-group

Reply via email to