Naively implemented directly-executed parser-combinators aren't any more powerful than recursive-descent. One thing I find interesting is that most discussions

Naively implemented directly-executed parser-combinators aren't any more powerful than recursive-descent. One thing I find interesting is that most discussions of recursive-descent don't actually show the algorithm. Let a grammar be a list of rules; let a rule be a list of prods (alternates); let a prod be a list of terms (references to rules, or terminals). Then, the recursive-descent algorithm is something along the lines of: def Parse(G, U): ''' G: the grammar; U: the user's state. ''' r = G.StartRule() return ParseRule(G, U, r) def ParseRule(G, U, r): potentials = [ ] for p in r: q = ParseProd(G, U, p) if q.success: potentials.append(q) return U.pickBest(potentials) def ParseProd(G, U, p): res = [ ] U.markTokens() for t in p: if t.isTerminal(): T = U.getToken() if t != T: return (False, [ ]) res.append(T) else: q = ParseRule(G, U, G.GetRule(t)) if not q[0]: return (False, [ ]) res.append(q[1]) U.commitTokens() return (True, res) I'm 100% sure this code leaves a lot off the table, but a reasonably complete recursive-descent algorithm is very close to this. I use the operator-overloading thing a lot of parser-combinators design as a way to specify the grammar in the native code, without going through a stringy-API.