BNF 中的括号，EBNF

Question

I could capture a parenthetical group using something like:

expr ::=    "(" <something> ")"

However, sometimes it's useful to use multiple levels of nesting, and so it's (theoretically) possible to have more than one parens as long as they match. For example:

>>> (1)+1
2
>>> (((((-1)))))+2
1
>>> ((2+2)+(1+1))
6
>>> (2+2))
SyntaxError: invalid syntax

Is there a way to specify a "matching-ness" in EBNF, or how is parenthetical-matching handled by most parsers?

Answer 1

In order to be able to match an arbitrary amount of anything (be it parentheses, operators, list items etc.) you need recursion (EBNF also features repetition operators that can be used instead of recursion in some cases, but not for constructs that need to be matched like parentheses).

For well-matched parentheses, the proper production is simply:

expr ::= "(" expr ")"

That's in addition to productions for other types of expressions, of course, so a complete grammar might look like this:

expr ::= "(" expr ")"
expr ::= NUMBER
expr ::= expr "+" expr
expr ::= expr "-" expr
expr ::= expr "*" expr
expr ::= expr "/" expr

Or for an unambiguous grammar:

expr        ::= expr "+" multExpr
expr        ::= expr "-" multExpr
multExpr    ::= multExpr "*" primaryExpr
multExpr    ::= multExpr "/" primaryExpr
primaryExpr ::= "(" expr ")"
primaryExpr ::= NUMBER

Also, how do you usually go about 'testing' that it is correct -- is there an online tool or something that can validate a syntax?

There are many parser generators that can accept some form of BNF- or EBNF-like notation and generate a parser from it. You can use one of those and then test whether the generated parser parses what you want it to. They're usually not available as online tools though. Also note that parser generators generally need the grammar to be unambiguous or you to add precedence declarations to disambiguate it.

also wouldn't infinite loop?

No. The exact mechanics depend on the parsing algorithm used of course, but if the character at the current input position is not an opening parenthesis, then clearly this isn't the right production to use and another one needs to be applied (or a syntax error raised if none of the productions apply).

Left recursion can cause infinite recursion when using top-down parsing algorithms (though in case of parser generators it's more likely that the grammar will either be rejected or in some cases automatically rewritten than that you get an actual infinite recursion or loop), but non-left recursion doesn't cause that kind of problem with any algorithm.