0

We're using GPPG (essentially bison for C#) to generate a parser for a programming language. Everything is going great except for one really nasty bit. The language we are parsing has a sort of "implicit comparison" rule, where "expression expression" should be interpreted as "expression == expression".

For example, this is a perfectly valid statement:

 If SomeValue False Then
 EndIf

This obviously introduces all sorts of conflicts during parser generation. My first attempt at solving them went something along these lines (edited for brevity). I tried to do some refactoring of the rules, and it doesn't seem to be ambiguous anymore, but I must just be missing something obvious.

Here is a very small grammar that shows the conflict I'm having, and how I've attempted to solve it, doesn't work though

%start program
%token <Token> Plus
%token <Token> Times
%token <Constant> Constant

%left Plus
%left Times
%left IMPLICIT_COMPARISON

%%

program: expression;

expressionBase: Constant
    | expression Plus expression
    | expression Times expression;

expression: expressionBase
    | expression expressionBase %prec IMPLICIT_COMPARISON;

%%

Any help would be greatly appreciated

LorenVS
  • 12,597
  • 10
  • 47
  • 54

1 Answers1

1

How about this:

program: expression;

expressionBase: Constant
    | expressionBase Plus expressionBase
    | expressionBase Times expressionBase;

expression: expressionBase 
    | expressionBase expression;

You need to build the grammar from bottom to top, not mixing your low-level concepts (like expressionBase) amd high-level ones (like expression). The high-level ones are build with the low-level ones. If you need it the other way around, you have to clearly delimit the high-level concept with parentheses or some such, like below:

expressionBase: Constant
    | expressionBase Plus expressionBase
    | expressionBase Times expressionBase
    | LeftParen expression RightParen;

The actual rules are rather more complicated but this should get you started.

n. m. could be an AI
  • 112,515
  • 14
  • 128
  • 243
  • Except that the precedence is wrong in your solution (not sure if it wrong in my example, didn't check, sry). Certain binary operators bind lower than the implicit comparison. For example, 2 3 == True could be interpeted as (2 == 3) == True, not 2 == ( 3 == True ) – LorenVS May 31 '11 at 05:51
  • hm... I might actually be able to make it work this way if I do it in 3 levels... One second, going to try – LorenVS May 31 '11 at 05:54
  • Hey thanks man, just got things working. Just had to split things into three levels for the high-binding binary operators, the implicit comparison, and then the low-binding binary operators... Thanks, just needed to think about it better :) – LorenVS May 31 '11 at 06:00
  • Well, the example doesn't define any explicit == operator, so I'm not sure how it could have any kind of precedence . If you want == to bind weaker than the implicit comparison, you either make another level dedicated to it, or play with the %prec declarations. If you want it to bind stronger, just add it to the expressionBase rule with an appropriate precedence. – n. m. could be an AI May 31 '11 at 06:13