Bison parser calculator

Download the "flex & bison" book by John Levine or the "bison" manual from gnu. Both contain an infix calculator that you can reference.

The grammar you have written " '(' expr_int ')'" reduces to expr_int before the grammatically incorrect ')' in "(1 + 1))' is detected. That is the parser does:

(1 + 1)) => ( expr_int )) => expr_int) 

and then sees the error. In order to capture the error you have to change the parser to see the error before the reduction, and you have to do it for all errors that you want treated. Therefore you would write (in this case):

expr_int '(' expr_int ')' ')' { this is an error message }

The short answer, after the long answer, is that it is impractical to generate a parser containing instances of all possible errors. What you have is fine for what you are doing. What you should explore is how to (gracefully) recover from an error rather than abandoning parsing.

Your "program" and "command" non-terminals can be combined as:

program: print-expr '\n' { return 0; } 

On a separate note, your regular expressions can be rewritten to good effect as:

%% INTEGER [0-9]+ WS [ \t]+ %% print/{WS} { return PRINT; } {INTEGER} { yylval.int_val=atoi(yytext); return INTEGER; } '(' { return '('; } ')' { return ')'; } '+' { return '+'; } '-' { return '-'; } {WS}* {} \n { return '\n'; } . { return *yytext; } // do you really want to do this? %% 

Create an end-of-line token (eg ;) for your language and make all lines statements exactly at the point when they encounter this end-of-line token.

Well that is because you are executing the code while parsing it. The good old bison calculator is meant to teach you how to write a grammar, not implement a full compiler/interpreter.

The normal way to build compiler/interpreter is the following:

lexer -> parser -> semantic analyser -> code generator -> interpreter 

Granted building a fully fledged compiler may be overkill in your case. What you need to to is store the result somewhere and only output it after yyparse has returned without an error.

In yacc/bison, the code associated with a semantic action is executed as soon as the rule in question is reduced, which may happen immediately after the tokens for the rule have been shifted, before looking at any following context to see if there's and error or not (a so-called "default" reduction, used to make the parse tables smaller).

If you want to avoid printing an answer until an entire line is read (and recognized), you need to include the newline in the rule that has the action that prints the message. In your case, you can move the newline from the program rule to the print_expr rule:

program: command { return 0; } ; print_expr: PRINT expr_int '\n' { cout<<$2<<endl; } 

Of course, this will still give you an error (after printing output) if you give it multiple lines of input.