2

mexp ::= (< mexp >) | < mexp >< mathlowop >< mexp > | < mulexp > | < float > | < var >

mulexp ::= < mexp >< mathhighop >< mexp >

mathlowop ::= + | -

mathhighop ::= / | *

That's the BNF I've come up with for parsing simple mathematical expressions where the operands can only be floats or variables. I've looked at a number of resources in books and on the web and for the same type of problem, they usually have a slightly longer, more complex bnf. Is my BNF incorrect in some way? Or is it correct but there is a significant advantage in doing it another way?

Rikaard
  • 21
  • 1
  • 1
  • 2

2 Answers2

7

Your grammar will generate mathematical expressions, but you haven't captured the notion of operator precedence. For instance, there are two different ways your grammar can generate the expression $a+a*a$, one having the interpretation we'd write as $a+[a*a]$ and the other having $[a+a]*a$. Using the jargon, we'd say your grammar is ambiguous.

A grammar that avoids this problem is

< expression > ::= < term > + < expression > | < term > - < expression > | < term >

< term > ::= < factor > * < term > | < factor > / < term > | < factor >

< factor > ::= (< expression >) | < float > | < var >

See if you can generate $a+a*a$ in two different ways using your grammar and then try the same thing with this grammar. That should give you an idea of what's going on here.

Rick Decker
  • 15,016
  • 5
  • 43
  • 54
1

If you are looking for a grammar, then yours is correct. If you are going to implement a parser, you might want to tweak your grammar a bit. It depends on the tools you are going to use.

mrk
  • 3,748
  • 23
  • 35