I want to implement the Parser for proposition logic which has the following operators in decreasing order of precedence:
- NOT p
- p AND q
- p OR q
- IF p THEN q
- p IFF q
- IF p THEN q ELSE r
The main issue is with the IF-THEN-ELSE operator. Without it, I am able to write the grammar properly. Presently my yacc file looks like
%term
PARSEPROG | AND | NOT | OR | IF | THEN | ELSE | IFF | LPAREN | RPAREN | ATOM of string | SEMICOLON | EOF
%nonterm
start of Absyn.program | EXP of Absyn.declaration
%start start
%eop EOF SEMICOLON
%pos int
%verbose
%right ELSE
%right IFF
%right THEN
%left AND OR
%left NOT
%name Fol
%noshift EOF
%%
start : PARSEPROG EXP (Absyn.PROGRAM(EXP))
EXP: ATOM ( Absyn.LITERAL(ATOM) )
| LPAREN EXP RPAREN (EXP)
| EXP AND EXP ( Absyn.CONJ(EXP1, EXP2) )
| EXP OR EXP ( Absyn.DISJ(EXP1, EXP2) )
| IF EXP THEN EXP ELSE EXP ( Absyn.IFTHENELSE(EXP1, EXP2, EXP3) )
| IF EXP THEN EXP ( Absyn.IMPLI(EXP1, EXP2) )
| EXP IFF EXP ( Absyn.BIIMPLI(EXP1, EXP2) )
| NOT EXP ( Absyn.NEGATION(EXP) )
But I don't seem to get the correct idea how to eliminate reduce-shift conflicts. Some examples of correct parsing are:
- IF a THEN IF b THEN c________a->(b->c)
- IF a THEN IF b THEN c ELSE d IFF e OR f_______IFTHENELSE(a,b->c,d<=>e/\f)
Any help/pointers will be really helpful. Thanks.
A relatively easy way to deal with this requirement is to create a grammar which over-generates, and then reject the syntax we don't want using semantics.
Concretely, we use a grammar like this:
Note that
ELSE
is just an ordinary low precedence operator: any expression can be followed byELSE
and another expression. But in the semantic rule, we implement a check that the left side ofELSE
is anIF
expression. If not, then we raise an error.This approach is not only easy to implement, but easy to document for the end-users and consequently easy to understand and use. The end user can accept the simple theory that
ELSE
is just another binary operator with a very low precedence, along with a rule which rejects it when it's not combined withIF/THEN
.Here is a test run from a complete program I wrote (using classic Yacc, in C):
Ordinary single
IF/ELSE
does what we want:The key thing that you're after:
correctly, the
ELSE
goes with the outerIF
. Here is the error case with badELSE
:Here is parentheses to force the usual "else with closest if" behavior:
The program shows what parse it is using by building an AST and then walking it to print it in prefix
F(X, Y)
syntax. (For which as a Lisp programmer, I had to hold back the gagging reflex a little bit).The AST structure is also what allows the
ELSE
rule to detect whether its left argument is an expression of the correct kind.Note: You might want the following to be handled, but it isn't:
The issue here is that the
ELSE w
is being paired with anIFELSE
expression.A more sophisticated approach is possible that might be interesting to explore. The parser can treat
ELSE
as an ordinary binary operator and generate theAST
that way. Then a whole separate walk can check the tree for validELSE
usage and transform it as necessary. Or perhaps we can play here with the associativity ofELSE
and treat cascadingELSE
in the parser action in some suitable way.The complete source code, which I saved in a file called
ifelse.y
and built using:is here: