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
-~----------~----~----~----~------~----~------~--~---
