The Wikipedia article describes what it means for a formal BNF grammar to be ambiguous. It has some interesting points but here are a few orthogonal points.
There are these stances towards ambiguity in a formal grammar:
- Ban it.
- Tolerate it with informal descriptions of which choice is made by the parser.
- Tolerate the grammar but reject syntactically ambiguous programs.
- Tolerate the grammar and reject programs that are semantically ambiguous.
A syntax may produce a program in two ways but the associated semantics may assign them the same meaning.
An objection to stance 2 is this scenario:
- A programmer understands part of the formal grammar correctly—an unambiguous part.
- He implements a program conforming to that part.
- The compiler accepts the program but interprets the program according to a different parsing.
- The program produces unexpected results.
Stance 2 is taken by many languages and is the only stance with this problem.
Most languages defined in mode 2 could adopt 3 and also provide compilers that would automatically provide alternate unambiguous versions of an ambiguous input, one for each parsing.
These alternates would have the respective semantics of the various parsings.
The partially informed user would presumably easily choose the one he meant.
IBM’s PL/I Checkout Compiler (circa 1960) would sometimes propose improvements to a program for the programmer’s approval.
A C example; in response to
if (a >= b) if(a==b) x(); else y();
the compiler would propose alternatives:
if (a >= b) {if(a==b) x();} else y();
if (a >= b) {if(a==b) x(); else y();}
It might volunteer that older compilers would have silently chosen the second.