No worries! I will take a look at this later. Thanks for the input. I'll also report on any findings from the jython list.
Best regards, -- Nuno Lopes On 13 Mar 2009, at 20:57, David Beazley wrote: > Some bad news. First, I still don't know why you get the weird > message on Jython. > > Some worse news. Your grammar actually *DOES* have shift-reduce > conflicts in it that PLY-2.5 was not reporting due to a bug in rule > precedence handling. The following CHANGES entry pertains to this: > > 01/06/09: beazley > Fixed a bug with precedence assignment. yacc was assigning > the precedence > each rule based on the left-most token, when in fact, it > should have been > using the right-most token. Reported by Bruce Frederiksen. > > Tracking down the source of the shift/reduce conflict is difficult > but it is related to these rules in your grammar and the handling of > DECLARE: > > def p_mainModule(p): > '''mainModule : prolog queryBody''' > > def p_prolog(p): > '''prolog : xqueryNS prolog > | sparqlNS prolog > | xqueryFunction prolog > | empty''' > > def p_xqueryFunction(p): > '''xqueryFunction : DECLARE FUNCTION qname LPAR paramList RPAR > enclosedExpr SEMICOLON''' > > def p_functionCall(p): > '''functionCall : qname LPAR exprSingles RPAR''' > > def p_qname(p): > '''qname : prefixedName > | unprefixedName > ... > | DECLARE > ... > "" > def p_xqueryFunction(p): > '''xqueryFunction : DECLARE FUNCTION qname LPAR paramList RPAR > enclosedExpr SEMICOLON''' > > If DECLARE is the next input token. > > 1. The parser could reduce the "empty" rule in "prolog" go > straight to parsing queryBody. > If you unwind the grammar, you will find that queryBody leads > directly to functionCall. > However, functionCall is prefaced by qname which accepts DECLARE > as a valid token. > > 2. Or, the parser could shift the DECLARE token on the stack and > try to match the > xqueryFunction rule. > > So, to summarize, the shift/reduce conflict is between the > xqueryFunction rule and the functionCall rule by way of some rather > hellish grammar rule expansion. Needless to say, I don't have much > advice on how you should go about fixing it. > > The good news : I don't think PLY-3.1 is broken. It seems to be > working better than PLY-2.5 in that it accurately caught this > conflict and reported it (whereas PLY was silent before). > > Good luck on this! Yikes! > > Cheers, > Dave > > > On Mar 13, 2009, at 1:54 PM, Nuno Lopes wrote: > >> >> Hi, >> >> >> On 13 Mar 2009, at 18:43, David Beazley wrote: >> >>> I will *DEFINITELY* need more information about this. There should >>> be no change in the number of shift/reduce conflicts between PLY 2.5 >>> and PLY 3.0. >> >> The full code is available at sourceforge: >> http://sourceforge.net/projects/xsparql >> >> The committed code gives no shift/reduces with ply-2.5 (just double >> checked, no errors on parser.out) but introduces the 4 shift/reduce >> with ply-3.1. >> >> Let me know if you need some more info. >> >> Thanks >> -- >> Nuno Lopes >> >> >> > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
