Hi everyone,

This is a question about how to direct the parser's Shift/Reduce
decisions (the setup is a bit long, sorry about that). Here goes:

I'm making a VBScript parser in PLY. For those unfamiliar with the
language, vbscript is full of design decisions that defy rational
explanation. Some of those decisions interact to make the grammar
ambiguous:
1 - assignment and equality comparison are both done with the =
operator
2 - array subscripts are written in parenthesis
3 - in some cases (don't ask) functions must be called without
sorrounding the arguments with parenthesis

As a result, the statement

anArray(aVar + 5) = anotherVar

can be interpreted in 2 different ways:
- assign to array "anArray", index "aVar + 5", the value of the
expression "anotherVar"
- call the function "anArray" with a single argument which is the
expression "(aVar + 5) = anotherVar" (funky isn't it?)

The above situation causes a shift/reduce conflict in my grammar. The
vbscript interpreter chooses the first option, so that's what I need
to do too. Here are the relevant (I think) parser states:

state 80

    (48) lvalue -> qualified_name ( indexlist . )
    (37) indexlist -> indexlist . , expression

    )               shift and go to state 112
    ,               shift and go to state 113

state 81

    (70) expression -> ( expression . )
    (38) indexlist -> expression .
    (49) expression -> expression . + expression
    (50) expression -> expression . - expression
    (51) expression -> expression . * expression
    (52) expression -> expression . / expression
    (53) expression -> expression . & expression
    (54) expression -> expression . EQUAL expression
    (55) expression -> expression . NOTEQ expression
    (56) expression -> expression . GT expression
    (57) expression -> expression . LT expression
    (58) expression -> expression . GE expression
    (59) expression -> expression . LE expression
    (60) expression -> expression . OR expression
    (61) expression -> expression . AND expression

  ! shift/reduce conflict for ) resolved as shift
    )               shift and go to state 95
    ,               reduce using rule 38 (indexlist -> expression .)
    +               shift and go to state 71
    -               shift and go to state 73
    *               shift and go to state 72
    /               shift and go to state 77
    &               shift and go to state 68
    EQUAL           shift and go to state 74
    NOTEQ           shift and go to state 69
    GT              shift and go to state 67
    LT              shift and go to state 75
    GE              shift and go to state 70
    LE              shift and go to state 76
    OR              shift and go to state 78
    AND             shift and go to state 65

  ! )               [ reduce using rule 38 (indexlist ->
expression .) ]

It took me a while to get my head around the problem (my grasp of
compiler theory is not that strong :), but now I can see why (48) (70)
and (38) result in a conflit and I'm pretty sure that reducing in this
case would give me the correct result.

I've read the part about precedence declarations (in fact I'm using
the example from there in my grammar, for the expression operators)
but I can't figure out how to apply that to this situation. I guess
part of my confusion is that the declaration of precedence rules is
done in function of tokens, which is intuitive for sorting between *
and + and the like, but not for this kind of thing. Everything I tried
had no effect on the grammar.
Is there a straighforward way to declare that a particular rule should
always reduce in case of conflict?
Can I rewrite the rules to break the conflict in the direction I want?
(I suspect the answer is yes, but how?)

Thanks for reading this far :)
Pedro

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

Reply via email to