   creating a simple calculator. need help with the EBNF
  I am creating a simple calculator where users would put an expression like: (5+3)/(3-5)*481, and then it outputs the result. To keep it simple, I'd like to just evaluate addition, multiplication, subtraction, and division, plus the parentheses. I am creating the EBNF right now and this is what I come up with:<digit> = '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'<number>= <unary operator> <digit>+ ['.' <digit>+]<unary operator> = '+' | '-'<operator>  = '+' | '-' | '*' | '/'<expression> = ( <expression> ) | <expression> <operator> <expression> | <number> <operator> <number>What do you guys think? Am I missing something? Have I considered all possible combinations?Thanks.#first edit after ToohrVyk's post   
  First, your numbers seem to be made out of other numbers (instead of digits).Also, you can only apply an operation to two numbers, which prevents you from having an expression such as 1+(2+3)   ;Quote:Original post by ToohrVykFirst, your numbers seem to be made out of other numbers (instead of digits).Ahh right right. I was editing lots of stuff and forgot that one.Quote:Also, you can only apply an operation to two numbers, which prevents you from having an expression such as 1+(2+3)Does <expression> <operator> <expression> do the job?   ;Quote:Does <expression> <operator> <expression> do the job?Almost. You would have a shift-reduce collision because of a situation like:1+2+3Which can be reduced to [1+2]+3 or shifted and reduced to 1+[2+3]. So you need to either introduce operator associativity (left-to-right) or find another syntax, such as:paren = ( expr )apply = numb oper expr | paren oper exprexpr = paren | numb | applyWhich would force 1+2+3 to be shifted to 1+[2+3] due to the numb oper expr rule (by saying there is no reduce, you remove shift-reduce conflicts).;  To avoid ambiguities and automatically gain the ability to handle operator precedence I would go with the following:<add>::= <multiply> (('+' | '-') <multiply>)*<multply> ::= <unary> (('*' | '/') <unary>)*<unary>   ::= ['+' | '-'] <unary> | <expression><expression>   ::= '(' <add> ')' | <number><number>  ::= <digit>+ ['.' <digit>+] <digit>   ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'Note:  I'm assuming your going to be parsing with a top-down recursive-descent parser (LL) as opposed to ToohrVyk's bottom-up approach (LR).arm.   ;Quote:Original post by alniteWhat do you guys think? Am I missing something? Have I considered all possible combinations?The grammar fails to accept these, for instance:(3) + 51 + 2 + 3This is because number is not an expression.EDIT: arm's grammar above works well, and imposes operator precedence. Take a look at it.   ;Quote:Original post by armTo avoid ambiguities and automatically gain the ability to handle operator precedence I would go with the following:<add>::= <multiply> (('+' | '-') <multiply>)*<multply> ::= <unary> (('*' | '/') <unary>)*<unary>   ::= ['+' | '-'] <unary> | <expression><expression>   ::= '(' <add> ')' | <number><number>  ::= <digit>+ ['.' <digit>+] <digit>   ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'Note:  I'm assuming your going to be parsing with a top-down recursive-descent parser (LL) as opposed to ToohrVyk's bottom-up approach (LR).arm.Hm...Good point. Does it accept (5*3)+2 though?;  Yes. The relevant parts of the parse tree will look like this:<add> |-<multiply> |  \-<unary> |\-<expression> |   |-'(' |   |-<add> |   |  \-<multiply> |   ||-'5' |   ||-'*' |   |\-'3' |   \-')' |-'+' \-'2';  I see. thanks people.   