Thanks, that makes sense. I will have to study what you suggested to see if I can understand this a little better. I actually changed the lexer in my program to recognize LPAREN OF as a single token, LPAREN_OF to get around the issue. The more I look at what you wrote, the more it seems to make sense, though.
Thanks, Carl On Oct 11, 3:35 pm, Bruce Frederiksen <[email protected]> wrote: > On Tue, Oct 6, 2009 at 4:31 PM, cwaldbieser <[email protected]> wrote: > > > def p_function(p): > > """ > > function : access_spec override_spec FUNCTION func_name > > generic_spec LPAREN arg_list RPAREN AS return_type > > """ > > p[0] = VBFunction("%s%s" % (p[4], p[5]), p[7], p[10], RT_VBFUNC) > > > def p_generic_spec(p): > > """ > > generic_spec : LPAREN OF type_param_spec_list > > RPAREN > > | > > """ > > The LPAREN after func_name produces a shift/reduce ambiguity for the two > generic_spec rules. > > Is: > > access_spec override_spec FUNCTION func_name LPAREN > > an empty generic_spec or not? Can't tell yet. But this is where the parser > must make a decision. > > If you rewrite the rules as: > > def p_function(p): > """ > function : access_spec override_spec FUNCTION func_name LPAREN > generic_spec arg_list RPAREN AS return_type > """ > ... > > def p_generic_spec(p): > """ > generic_spec : OF type_param_spec_list RPAREN LPAREN > | > """ > > Then you shouldn't have this problem. With the new rules, the parser > doesn't have to decide between an empty generic_spec or not until the next > token after the first LPAREN. If it sees OF, it's a generic_spec, otherwise > not and generic_spec is empty. > > Hope this helps! > > -Bruce --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "ply-hack" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/ply-hack?hl=en -~----------~----~----~----~------~----~------~--~---
