Context-Free Grammar — Fixing Ambiguous Parser Failures

Every time you hit compile and your IDE catches a missing semicolon before running a single line, a CFG is quietly doing that job. Compilers for C, Java, Python, SQL — every one of them is built on top of a formal grammar that precisely defines what 'valid code' looks like. CFGs aren't an academic curiosity; they're the load-bearing wall of language design.

Before CFGs existed, language recognizers were brittle, hand-coded state machines that couldn't handle nested structures like balanced parentheses or recursive function calls. Regular expressions — powerful as they are — can't count. They can't verify that every opening brace has a matching closing brace. CFGs solve exactly this problem by introducing recursive production rules that can describe arbitrarily deep nesting with a handful of compact rules.

By the end of this article you'll be able to write your own CFG for a mini expression language, trace through a derivation by hand, build a recursive-descent parser from those production rules in Java, spot ambiguity before it bites you in production, and answer the CFG questions that senior compiler-track interviewers love to ask.

How Context-Free Grammar Defines Structure Without Ambiguity

A context-free grammar (CFG) is a set of recursive rewriting rules that generate all valid strings in a formal language. Each rule maps a nonterminal symbol to a sequence of terminals and nonterminals — for example, Expr → Expr '+' Term | Term. The key mechanic: the left side is always a single nonterminal, never dependent on surrounding symbols (hence "context-free"). This makes CFGs ideal for describing programming language syntax, where nested structures like parentheses or if-blocks must be parsed unambiguously.

In practice, a CFG defines a parse tree: the root is the start symbol, interior nodes are nonterminals, and leaves are tokens. The grammar is unambiguous if every valid input produces exactly one leftmost derivation. Tools like ANTLR or JavaCC convert CFGs into parsers that run in O(n) time using lookahead. The critical property is that CFGs can express recursion — enabling constructs like nested arithmetic expressions or JSON objects — without needing a Turing-complete machine.

Use a CFG whenever you need to validate or interpret structured text: configuration files, query languages, or custom DSLs. Without it, hand-written parsers quickly degenerate into brittle spaghetti code that fails on edge cases. A well-designed CFG gives you a formal specification that is testable, maintainable, and portable across parser generators — essential for any system that ingests user-defined input.

Formal Definition of a CFG

Each production rule describes how a non-terminal can be replaced by a string of terminals and non-terminals. The term 'context-free' means the rule applies regardless of the surrounding symbols — no context is needed. This is what allows nesting and recursion, but also introduces ambiguity when multiple rules can expand the same non-terminal in conflicting ways.

Let's dissect that with a real example. For a simple arithmetic grammar: V = {Exp, Term, Factor} Σ = {+, , (, ), num} R = { Exp → Exp + Term | Term, Term → Term Factor | Factor, Factor → ( Exp ) | num } S = Exp

Notice how Exp can rewrite to itself plus a Term — that's left recursion, which is fine for bottom-up parsers, but top-down parsers require elimination. Also notice the precedence hierarchy: multiplication is one level below addition, so it binds tighter.

In a production grammar, you'll often have dozens or hundreds of non-terminals. A real language like Java has around 80 non-terminals and hundreds of productions. Managing that by hand is error-prone — that's why parser generators like ANTLR and Bison exist. The trade-off is learnability: parser generators hide the complexity but you must understand conflicts and precedence to debug them.

package io.thecodeforge.cfg;

import java.util.*;

public record GrammarDefinition(
    Set<String> nonTerminals,
    Set<String> terminals,
    Map<String, List<List<String>>> productions,
    String startSymbol
) {
    public GrammarDefinition {
        nonTerminals = Set.copyOf(nonTerminals);
        terminals = Set.copyOf(terminals);
        productions = Map.copyOf(productions);
    }

    public boolean isNonTerminal(String symbol) {
        return nonTerminals.contains(symbol);
    }

    public boolean isTerminal(String symbol) {
        return terminals.contains(symbol);
    }

    public List<List<String>> getProductionsFor(String nonTerminal) {
        return productions.getOrDefault(nonTerminal, List.of());
    }

    public static GrammarDefinition balancedParensGrammar() {
        Set<String> nonTerminals = Set.of("S");
        Set<String> terminals = Set.of("(", ")");
        Map<String, List<List<String>>> productions = new HashMap<>();
        productions.put("S", List.of(
            List.of("(", "S", ")"),
            List.of("(", ")")
        ));
        return new GrammarDefinition(nonTerminals, terminals, productions, "S");
    }
}

Derivations and Parse Trees

A derivation is a sequence of production rule applications that starts with the start symbol and ends with a string of only terminals. Each step replaces one non-terminal with the right-hand side of a matching production. The resulting structure can be visualised as a parse tree, where the root is the start symbol, internal nodes are non-terminals, leaves are terminals, and children of a node correspond to the symbols in the production used.

Leftmost derivation always replaces the leftmost non-terminal; rightmost derivation always replaces the rightmost. Both produce the same parse tree for an unambiguous grammar. Parse trees are the foundation of syntax-directed translation: compilers attach semantic actions to tree nodes.

Here's a concrete derivation for the string "2 + 3" using our arithmetic grammar: Exp → Exp + Term (leftmost) → Term + Term → Factor + Term → 2 + Term → 2 + Factor → 2 + 3

The parse tree would have Exp at root, with children Exp, +, Term. And so on. In production, you don't usually build the full parse tree — you build an Abstract Syntax Tree (AST) that prunes away unnecessary nodes like single-child productions. That's a memory savings of 40-60% on typical code.

When you debug a parser, tracing the derivation is often the fastest way to find why certain inputs fail. Tools like ANTLR's -trace option output the derivation steps, which is invaluable.

package io.thecodeforge.cfg;

import java.util.*;

public class ParseTree {
    private final String symbol;
    private final List<ParseTree> children;

    public ParseTree(String symbol, List<ParseTree> children) {
        this.symbol = symbol;
        this.children = children;
    }

    public static ParseTree fromDerivation(String start, Map<String, List<List<String>>> prods) {
        // Simplified: builds tree from leftmost derivation steps
        // In practice, the parser outputs this structure
        return new ParseTree(start, List.of());
    }

    public void print(String indent) {
        System.out.println(indent + symbol);
        for (ParseTree child : children) {
            child.print(indent + "  ");
        }
    }

    // Add method to compute AST by removing single-child nodes
    public ParseTree toAST() {
        if (children.size() == 1 && children.get(0).children.size() > 0) {
            return children.get(0).toAST();
        }
        List<ParseTree> astChildren = new ArrayList<>();
        for (ParseTree child : children) {
            astChildren.add(child.toAST());
        }
        return new ParseTree(symbol, astChildren);
    }
}

Ambiguity in CFGs and How to Resolve It

A grammar is ambiguous if some string in its language has more than one distinct parse tree (or equivalently, more than one leftmost derivation). Ambiguity is a serious problem in compilers because it means the same source code can have multiple meanings — the compiler cannot choose which one is intended. Classic examples include the 'dangling else' problem in C-like languages and operator precedence for arithmetic expressions.

Resolving ambiguity: Restructure the grammar to enforce precedence and associativity. For example, instead of a single non-terminal for expressions, break it into multiple levels (Expr, Term, Factor). Use left recursion for left-associative operators. Parser generators like ANTLR also allow disambiguating predicates or semantic actions, but the cleanest solution is a non-ambiguous grammar.

Here's the classic ambiguous arithmetic grammar: E → E + E | E E | n For input "1 + 2 3", you get two parse trees: one treating it as (1+2)3, the other as 1+(23). That's a bug for any calculator. The fix is to introduce precedence levels as shown earlier.

In production, ambiguity can lead to security vulnerabilities. If an attacker can craft input that parses differently than intended, they might bypass validation. That's why SQL injection often exploits ambiguous grammar in SQL dialects.

package io.thecodeforge.cfg;

public class AmbiguityExample {
    // Ambiguous grammar: E → E + E | E * E | n
    // String "1 + 2 * 3" has two parse trees:
    // Tree1: (1 + 2) * 3
    // Tree2: 1 + (2 * 3)
    
    // Unambiguous version with precedence:
    // E → E + T | T
    // T → T * F | F
    // F → n | ( E )
    
    public static void main(String[] args) {
        System.out.println("Ambiguous: E → E+E | E*E | n");
        System.out.println("String '1+2*3' yields two parse trees.");
        System.out.println("Use precedence levels to disambiguate.");
    }
}

Writing a CFG for a Mini Expression Language

Let's design a small expression language that supports addition, multiplication, parentheses, and integer literals. We'll follow the standard precedence hierarchy (multiplication binds tighter than addition) and left associativity for both operators.

Grammar (unambiguous): Exp → Exp + Term | Term Term → Term * Factor | Factor Factor → ( Exp ) | num

This grammar ensures that '+' sees '*' as a subexpression on the right, so multiplication happens first. The left recursion ensures left associativity: '1 + 2 + 3' parses as ((1+2)+3). We'll also handle whitespace and negative numbers by making 'num' a terminal that includes optional minus sign (or separate unary minus later).

Extending this grammar is straightforward: add a new non-terminal for each new precedence level. For example, to add exponentiation (right-associative), you'd insert: Factor → Factor ^ Unary | Unary Unary → ( Exp ) | num

This pattern scales to any language. In real parsers like GCC, there are around 15 precedence levels for C expressions. Each level is a non-terminal.

One nuance: left-recursive rules are fine for bottom-up parsers (Bison) but cause infinite recursion in top-down parsers. For recursive descent, you'll transform left recursion into iteration (while loop) as shown in the next section.

package io.thecodeforge.cfg;

import java.util.*;

public class ExpressionGrammar {
    public static Map<String, List<List<String>>> buildProductions() {
        Map<String, List<List<String>>> prods = new LinkedHashMap<>();
        prods.put("Exp", List.of(
            List.of("Exp", "+", "Term"),
            List.of("Term")
        ));
        prods.put("Term", List.of(
            List.of("Term", "*", "Factor"),
            List.of("Factor")
        ));
        prods.put("Factor", List.of(
            List.of("(", "Exp", ")"),
            List.of("num")
        ));
        return prods;
    }

    public static void main(String[] args) {
        var prods = buildProductions();
        System.out.println("Production rules:");
        prods.forEach((k, v) -> {
            for (List<String> rhs : v) {
                System.out.println(k + " → " + String.join(" ", rhs));
            }
        });
    }
}

Building a Recursive Descent Parser in Java

A recursive descent parser is a top-down parser that directly mirrors the grammar's production rules. Each non-terminal becomes a method. For each production of that non-terminal, the method tries to match the input tokens sequentially. If one production fails, it backtracks (or uses lookahead to choose deterministically). For our expression grammar, we'll implement a simple version that uses a lookahead token (LL(1) with a single token peek) to decide between alternatives.

The parser consumes tokens from a lexer. Our methods: parseExp(), parseTerm(), parseFactor(). Each returns an AST node or performs actions. We'll keep it simple: evaluate the expression on the fly (calculator style). The code below demonstrates the structure.

Key observation: the left recursion in the grammar becomes a while loop in the parser. That's a standard pattern — instead of recursive calls, use iteration for left associative operators. This avoids stack overflows. The same pattern works for addition, multiplication, and other left-assoc operators.

In production, you'd probably use a parser generator. But knowing how to build a recursive descent parser by hand is invaluable when you're using a tool like ANTLR and need to understand what it generates.

package io.thecodeforge.parser;

import java.util.*;

public class RecursiveDescentParser {
    private final List<String> tokens;
    private int pos = 0;

    public RecursiveDescentParser(List<String> tokens) {
        this.tokens = tokens;
    }

    // Exp → Exp + Term | Term
    public int parseExp() {
        int val = parseTerm();
        while (match("+")) {
            int right = parseTerm();
            val += right;
        }
        return val;
    }

    // Term → Term * Factor | Factor
    public int parseTerm() {
        int val = parseFactor();
        while (match("*")) {
            int right = parseFactor();
            val *= right;
        }
        return val;
    }

    // Factor → ( Exp ) | num
    public int parseFactor() {
        if (match("(")) {
            int val = parseExp();
            expect(")");
            return val;
        }
        // Assume token is a number
        String token = consume();
        return Integer.parseInt(token);
    }

    private boolean match(String expected) {
        if (pos < tokens.size() && tokens.get(pos).equals(expected)) {
            pos++;
            return true;
        }
        return false;
    }

    private String consume() {
        if (pos >= tokens.size()) throw new RuntimeException("Unexpected end of input");
        return tokens.get(pos++);
    }

    private void expect(String expected) {
        String actual = consume();
        if (!actual.equals(expected))
            throw new RuntimeException("Expected '" + expected + "' but got '" + actual + "'");
    }

    public static void main(String[] args) {
        // Input: "2 + 3 * 4" -> tokens: ["2", "+", "3", "*", "4"]
        List<String> tokens = Arrays.asList("2", "+", "3", "*", "4");
        RecursiveDescentParser parser = new RecursiveDescentParser(tokens);
        int result = parser.parseExp();
        System.out.println("Result: " + result);  // Should be 14 (not 20)
    }
}

Leftmost vs. Rightmost Derivations: Why Order Matters in the Parse

When you derive a string from a grammar, you have a choice: which non-terminal to expand first? Your parser doesn't care about the order, but it cares deeply about which path leads to a valid parse tree. Leftmost derivation always expands the leftmost non-terminal. Rightmost does the opposite. Both can produce the exact same parse tree if the grammar is unambiguous. The moment you hit ambiguity, leftmost and rightmost derivations diverge — and that's where your parser breaks.

Why does this matter in production? Because deterministic parsers (like LL and LR) are built around a single derivation order. An LL(1) parser commits to productions based on leftmost derivation decisions. An LR parser builds a rightmost derivation in reverse. Pick the wrong grammar for your parser type, and you get shift-reduce conflicts, left recursion blowups, or ambiguous parses that silently corrupt your AST. The order is baked into your parser's DNA.

// io.thecodeforge — cs-fundamentals tutorial

# Grammar: E -> E + T | T
# Grammar: T -> int | ( E )

# String: int + int + int

# Leftmost derivation:
# E -> E + T -> E + T + T -> T + T + T -> int + T + T -> int + int + T -> int + int + int

# Rightmost derivation:
# E -> E + T -> E + E + T -> E + E + int -> E + T + int -> E + int + int -> T + int + int -> int + int + int

print("Both produce the same parse tree.")
print("Leftmost: reflects top-down parser choices.")
print("Rightmost: reflects bottom-up parser reduction order.")

Sentential Forms: The Intermediate State Between Start and Yield

A derivation isn't magic — it's a sequence of sentential forms. Every step, you apply a production to replace one non-terminal with a string of terminals and non-terminals. The start symbol is the first sentential form. The final string of terminals is the last. Everything in between? Those are the intermediate shapes your grammar takes.

For example, with the grammar S -> aSb | ε, the sentential forms for deriving "aabb" are: S, aSb, aaSbb, aabb. Each one is a valid snapshot. Understanding sentential forms isn't just academic — it's how you spot dead ends in a parse. When you're debugging a shift-reduce conflict, you stare at sentential forms to see where the parser gets stuck. Every ambiguity problem you've ever debugged can be traced back to a single sentential form where two distinct derivations converge.

Most devs skip this concept and then wonder why their hacky recursive descent parser falls apart on nested expressions. Sentential forms are your debug map. Learn them.

// io.thecodeforge — cs-fundamentals tutorial

def derive_sentential_forms(rules, start, target):
    stack = [start]
    while stack:
        current = stack.pop()
        print(f"Current form: {current}")
        if current == target:
            return
        for lhs, rhs in rules:
            if lhs in current:
                new_form = current.replace(lhs, rhs, 1)
                if len(new_form) <= len(target):
                    stack.append(new_form)
                    break

# Grammar: S -> aSb | ε (palindrome-like)
rules = [
    ("S", "aSb"),
    ("S", ""),  # epsilon
]

derive_sentential_forms(rules, "S", "aabb")

Left Recursion and Right Recursion: The Parser Killer You Ignore

Left recursion is when a production calls itself as the leftmost symbol: E -> E + T. Right recursion is the opposite: E -> T + E. They sound symmetric, but they break your parser asymmetrically.

Top-down parsers (LL, recursive descent) choke on left recursion. They try to expand E, see E, try to expand E again — infinite recursion before you even parse one token. Bottom-up parsers (LR, LALR) love left recursion because it compresses into a tight deterministic loop. Right recursion is fine for top-down parsers, but it blows up your stack depth because each nested term creates a new call frame.

The fix? Transform left recursion into right recursion using a mechanical refactor: E -> E + T becomes E -> T E', E' -> + T E' | ε. It's ugly, it's awkward, but your parser stops dying. Every production-grade compiler I've shipped did this transformation at some point. You will too.

Don't trust your grammar until you've checked every recursive rule for left recursion. The parser will thank you later.

// io.thecodeforge — cs-fundamentals tutorial

# Before (left-recursive - breaks top-down parsers):
# E -> E + T | T
# T -> int

# After (right-recursive - safe for top-down):
# E  -> T E'
# E' -> + T E' | ε
# T  -> int

def parse_expression(tokens):
    # Right-recursive descent parser
    def parse_T(tokens):
        if tokens and tokens[0] == 'int':
            tokens.pop(0)
            return True
        return False

    def parse_E_prime(tokens):
        if tokens and tokens[0] == '+':
            tokens.pop(0)
            if not parse_T(tokens):
                return False
            return parse_E_prime(tokens)
        return True  # epsilon

    def parse_E(tokens):
        if not parse_T(tokens):
            return False
        return parse_E_prime(tokens)

    return parse_E(tokens)

# Test
print(parse_expression(['int', '+', 'int', '+', 'int']))  # True
print(parse_expression(['int', '+', 'int']))  # True

Designing a CFG: Stop Guessing, Start Decomposing

Most engineers break down when asked to write a grammar because they try to reverse-engineer strings instead of thinking about structure. A grammar is a system of recursive decomposition: start with the highest-level construct (e.g., an expression) and split it into its parts (terms, factors, primaries). Each nonterminal should represent one syntactic role, never more.

Don't write a single rule that tries to handle addition, multiplication, and parentheses together. That's how you breed ambiguity and left recursion. Instead, layer your rules: Expr delegates to Term (handles multiplicative precedence), Term delegates to Factor (handles primaries and parens). Each layer owns exactly one precedence level and recurses via a single operator.

Your grammar mirrors your parser's call stack. If you design it with hierarchical decomposition from day one, you eliminate ambiguous derivations and produce clean, predictable parse trees. That's not theory — that's debugging time you won't waste.

// io.thecodeforge — cs-fundamentals tutorial

# A mini arithmetic grammar: layered by precedence
# Expr -> Expr '+' Term | Term
# Term -> Term '*' Factor | Factor
# Factor -> '(' Expr ')' | 'num'

class Expr:
    def __init__(self):
        self.choices = [
            (['Expr', '+', 'Term'], self._add),
            (['Term'], self._term),
        ]

    def _add(self, left, _, right):
        return ('+', left, right)

    def _term(self, term):
        return term

# Output: string '2+3*4' produces (+, num, (*, num, num))
print(parse('2+3*4'))

Limitations of CFGs: Where They Break and You Need More Power

A CFG cannot count. It cannot ensure that the number of opening and closing brackets matches across nested contexts, nor can it enforce variable declaration before use or type consistency. Those constraints require context — information passed between branches of a parse tree. CFGs are context-free; they don't pass any state sideways.

Think about a language where you must declare a variable before you reference it, and declarations can be nested inside blocks. A CFG can describe the block structure perfectly, but it can't verify that x is defined when you write x + 1. That's a semantic constraint, not a syntactic one. You either push it to a later analysis phase (semantic analysis, symbol table) or upgrade to a context-sensitive grammar — which most real compilers never do because it's impractical.

Production engineers know: use CFGs for syntax, accept that semantic checks require separate passes. Trying to force context-sensitivity into a CFG is a fool's errand that produces unmaintainable monstrosities. Know the boundary, and don't cross it.

// io.thecodeforge — cs-fundamentals tutorial

# CFG can't enforce: 'variable used must be declared first'
# This grammar parses but semantic check must reject it

import re

def parse_decl_use(program):
    # Grammar: Stmt -> 'int' ID ';' | ID '=' num ';'
    # Parser accepts both, semantic check fails x=3; y=x;
    if re.search(r'^int [a-z]+ = \d+;', program):
        return True  # syntactic OK
    return False

# Program: 'int x = 1; y = x;' parses but semantic error
print(parse_decl_use('int x = 1; y = x;'))

LL vs LR Parsing: When to Use Each

LL and LR parsing are two fundamental strategies for building parsers from context-free grammars. LL parsers (top-down) construct a leftmost derivation, reading input left-to-right and producing a leftmost derivation. They are simpler to implement by hand (e.g., recursive descent) and work well for grammars that are LL(k) — meaning they can decide which production to use by looking ahead k tokens. However, LL parsers cannot handle left recursion and may struggle with ambiguity. LR parsers (bottom-up) construct a rightmost derivation in reverse, reading input left-to-right. They are more powerful, handling a larger class of grammars (LR(k)) including left-recursive and many ambiguous grammars when augmented with precedence rules. LR parsers are typically generated by tools like Yacc or Bison and are used in production compilers for languages like C and Java. When to use each? Use LL for hand-written parsers, simple languages, or when you need clear error messages. Use LR for complex languages, when grammar size is large, or when you need maximum parsing power. A practical example: a calculator with operator precedence is easy to write as an LL parser using precedence climbing, but an LR parser can handle it directly with shift-reduce actions. In summary, LL is simpler and more transparent; LR is more powerful and efficient for complex grammars.

// LL(1) grammar for simple expressions (no left recursion)
E  -> T E'
E' -> + T E' | ε
T  -> F T'
T' -> * F T' | ε
F  -> ( E ) | id

// LR(1) grammar for same language (can be left-recursive)
E  -> E + T | T
T  -> T * F | F
F  -> ( E ) | id

Parser Combinators: A Modern Alternative to Parser Generators

Parser combinators are a functional programming technique for building parsers by composing small, reusable parsing functions. Unlike parser generators (e.g., Yacc, ANTLR) which generate code from a grammar specification, parser combinators are embedded directly in a host language (like Haskell, Scala, or Rust) and allow you to define parsers as first-class values. This approach offers several advantages: no separate build step, easy debugging with native stack traces, and seamless integration with the host language's type system and tooling. For example, in Scala, you can define a parser for arithmetic expressions using combinators like ~, |, and map. A practical example: parsing a comma-separated list of numbers: val number = """\d+""".r ^^ (_.toInt); val list = number ~ rep("," ~> number). Parser combinators are especially useful for domain-specific languages (DSLs) and prototyping, where grammar changes frequently. However, they can be slower than generated parsers and may have issues with left recursion (though some libraries handle it). Modern libraries like Parboiled2 (Scala), Nom (Rust), and Megaparsec (Haskell) provide efficient implementations. In summary, parser combinators offer flexibility and expressiveness at the cost of performance; they are ideal for small to medium-sized languages and projects where maintainability is key.

import scala.util.parsing.combinator._

object ArithParser extends RegexParsers {
  def expr: Parser[Int] = term ~ rep("+" ~> term | "-" ~> term) ^^ {
    case t ~ rest => rest.foldLeft(t) {
      case (x, "+" ~ y) => x + y
      case (x, "-" ~ y) => x - y
    }
  }
  def term: Parser[Int] = factor ~ rep("*" ~> factor | "/" ~> factor) ^^ {
    case f ~ rest => rest.foldLeft(f) {
      case (x, "*" ~ y) => x * y
      case (x, "/" ~ y) => x / y
    }
  }
  def factor: Parser[Int] = """\d+""".r ^^ (_.toInt) | "(" ~> expr <~ ")"
}

ArithParser.parseAll(ArithParser.expr, "3+4*5") match {
  case ArithParser.Success(result, _) => println(result) // 23
  case _ => println("Parse error")
}

Grammar Ambiguity Detection and Resolution

Ambiguity in context-free grammars occurs when a single string can be derived in multiple ways, leading to different parse trees. This is problematic for parsers because it creates nondeterminism. Detecting ambiguity is undecidable in general, but practical heuristics exist. Common sources: dangling else (if-then-else), operator precedence, and associativity. For example, the grammar E -> E + E | id is ambiguous because id+id+id has two leftmost derivations. To detect ambiguity, you can use tools like ANTLR's ambiguity detection or manually check for conflicts in LL/LR tables. Resolution techniques include: refactoring the grammar (e.g., introducing nonterminals for precedence levels), using precedence and associativity declarations (as in Yacc), or employing GLR parsing (which handles ambiguity by exploring all parses). A practical example: the classic dangling-else ambiguity is resolved by matching each else with the nearest unmatched if, which can be enforced by grammar restructuring or by parser directives. In Java, a recursive descent parser can resolve ambiguity by ordering alternatives (e.g., try the longer match first). For complex grammars, consider using an ambiguous grammar with a disambiguation filter (e.g., operator precedence parser). In summary, while full detection is impossible, most real-world ambiguities can be identified and resolved through careful grammar design and parser configuration.

%token NUMBER
%left '+' '-'
%left '*' '/'
%%
expr: expr '+' expr
    | expr '-' expr
    | expr '*' expr
    | expr '/' expr
    | NUMBER
    ;
%%
// Precedence and associativity declarations resolve ambiguity:
// '*' and '/' have higher precedence than '+' and '-',
// all operators are left-associative.