Thread: Bison/Yacc Recursion Problem - "Rule never reduced because of conflicts"

  1. #1
    Magically delicious LuckY's Avatar
    Join Date
    Oct 2001
    Posts
    856

    Bison/Yacc Recursion Problem - "Rule never reduced because of conflicts"

    I'm suffering a problem with a yacc specification. I had a similar problem but was able to resolve it. I'm sure the problem is in the recursion madness I'm dealing with, but am unable to find a clear way around it. Any ideas?

    Here're the related bits:
    Code:
    atomic_patt : CONSTANT_TK
                | UNDERSCORE_TK
                | LPAREN_TK  pattern_star  RPAREN_TK
                | LBRACE_TK  pattern_star  RBRACE_TK
                | IDENT_TK
                ;
    
    pattern_star : /* epsilon */
                 | pattern
                 | pattern  COMMA_TK  pattern_star
                 ;
    
    pattern : pattern_qual_id  atomic_patt  pattern_type
            | atomic_patt  CONS_TK  atomic_patt
            ;
    
    pattern_qual_id : /* epsilon */  <============= line 152
                    | qual_id
                    ;
    
    pattern_type : /* epsilon */
                 | COLON_TK  type
                 ;
    
    qual_id : IDENT_TK
            | IDENT_TK  DOT_TK  qual_id
            ;
    And the error (warning really, but hey):
    Quote Originally Posted by Bison
    mwb.y:152.16: warning: rule never reduced because of conflicts: pattern_qual_id: /* empty */

  2. #2
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,708
    not sure - what is the meaning of the /* epsilon */ in place of a rule?
    and shouldn't the longer rules be defined first:

    | pattern
    | pattern COMMA_TK pattern_star

    seems to me the second would never get evaluated (or does bison account for that)?
    Code:
    #include <cmath>
    #include <complex>
    bool euler_flip(bool value)
    {
        return std::pow
        (
            std::complex<float>(std::exp(1.0)), 
            std::complex<float>(0, 1) 
            * std::complex<float>(std::atan(1.0)
            *(1 << (value + 2)))
        ).real() < 0;
    }

  3. #3
    Magically delicious LuckY's Avatar
    Join Date
    Oct 2001
    Posts
    856
    The epsilon represents nothing. In other words a regular expression like ab?c could be accpeted by a grammar like:
    Code:
    S -> aTc
    T -> b | epsilon
    In any case, I have found the problem, and it was in "pattern." The problem was that Bison could not determine if it should choose the first or second production because pattern_qual_id could evaluate to epsilon which would then make both productions begin with atomic_patt. So instead of using the epsilon, I just split the two options into two productions.

    The correction of pattern looks like this (and pattern_qual_id is now gone):
    Code:
    pattern : atomic_patt  pattern_type
            | qual_id atomic_patt  pattern_type
            | atomic_patt  CONS_TK  atomic_patt
            ;

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Recursion Funtion Problem
    By Unregistered in forum C++ Programming
    Replies: 1
    Last Post: 04-26-2002, 06:44 AM
  2. Recursion Problem
    By Unregistered in forum C++ Programming
    Replies: 0
    Last Post: 04-25-2002, 06:59 PM
  3. problem with output
    By Garfield in forum C Programming
    Replies: 2
    Last Post: 11-18-2001, 08:34 PM
  4. recursion problem
    By ender in forum C++ Programming
    Replies: 1
    Last Post: 11-11-2001, 02:25 PM
  5. recursion problem
    By dustinc in forum C++ Programming
    Replies: 1
    Last Post: 10-29-2001, 04:29 AM