EXTENDED BACKUS – NAUR FORM (EBNF)

• Because of a few minor inconveniences in BNF, it has been extended in several ways. Most extended versions are called Extended BNF, or simply EBNF, even though they are not all exactly the same.
• Three extensions are commonly included in the various versions of EBNF.
• The first of these denotes an optional part of an RHS, which is delimited by brackets. For example, an if-else statement can be described as
  <if_stmt> → if (<expression>) <statement> [else <statement>]
  without the use of the brackets, the syntactic description of this statement would require the following two rules:
  <if_stmt> → if (<expression>) <statement>
        | if (<expression>) <statement> else <statement>
• The second extension is the use of braces in an RHS to indicate that the enclosed part can be repeated indefinitely or left out altogether. This extension allows lists to be built with a single rule, instead of using recursion and two rules. For example, lists of identifiers separated by commas can be described by the following rule:
  <ident_list> → <identifier> { , <identifier> }
  This is a replacement of the recursion by a form of implied iteration; the part enclosed within braces can be iterated any number of times.
• The third common extension deals with multiple-choice options. When a single element must be chosen from a group, the options are placed in parentheses and separated by the OR operator, |. For example,
  <term> → <term> ( * | / | % ) <factor>
  In BNF, a description of this would require the following three rules:
  <term> → <term> * <factor>
       | <term> / <factor>
       | <term> % <factor>
• The brackets, braces, and parentheses in the EBNF extensions are meta-symbols, which means they are notational tools and not terminal symbols in the syntactic entities they help describe.
• These meta-symbols are also terminal symbols in the language, the instances that are terminal symbols can be underlined or quoted.
• EXAMPLE: BNF and EBNF Versions of an Expression Grammar
  BNF:
  <expr> → <expr> + <term>
       | <expr> - <term>
       | <term>
  <factor> → <expr> ** <factor>
        |<expr>
  <expr> → (<expr>)
       | id
  EBNF:
  <expr> → <term> { ( + | - ) <term> }
  <factor> → <expr> { ** <expr> }
  <expr> → (<expr>)
       | id
• The BNF rule
    <expr> → <expr> + <term>
  clearly specifies—in fact forces—the + operator to be left associative. However, the EBNF version,
    <expr> → <term> { + <term> }
  does not imply the direction of associativity.
• This problem is overcome in a syntax analyzer based on an EBNF grammar for expressions by designing the syntax analysis process to enforce the correct associativity.
• some variations on BNF and EBNF have appeared. Among these are the following:
  • In place of the arrow, a colon is used and the RHS is placed on the next line.
  • Instead of a vertical bar to separate alternative RHSs, they are simply placed on separate lines.
  • In place of square brackets to indicate something being optional, the subscript opt is used. For example,
      Constructor Declarator → SimpleName (FormalParameterList_opt)
  • Rather than using the | symbol in a parenthesized list of elements to indicate a choice, the words “one of ” are used. For example,
    AssignmentOperator → one of = *= /= %= += -= <<= >>= &= ^= |=