In the general case, recursive descent parsers are not limited to the Context-free grammar and thus do no global search for ambiguities in the LL(k) parsing First_k and Follow_k sets. Thus ambiguities are not known until run-time if and until the input triggers them. Such ambiguities where the recursive descent parser defaults (perhaps unknown to the grammar designer) to one of the possible ambiguous paths, thus results in semantic confusion (aliasing) in the use of the language, and leads to bugs by users of ambiguous programming languages which are not reported at compile-time, and which are introduced not by human error, but by ambiguous grammar. The only solution which eliminates these bugs, is to remove the ambiguities and use a Context-free grammar.

http://en.wikipedia.org/w/index.php?title=Parser_combinator&oldid=407998210#Shortcomings_and_solutions

Parser combinators, like all recursive descent parsers, are not limited to the Context-free grammar and thus do no global search for ambiguities in the LL(k) parsing First_k and Follow_k sets. Thus ambiguities are not known until run-time if and until the input triggers them. Such ambiguities where the recursive descent parser defaults (perhaps unknown to the grammar designer) to one of the possible ambiguous paths, thus results in semantic confusion (aliasing) in the use of the language, and leads to bugs by users of ambiguous programming languages which are not reported at compile-time, and which are introduced not by human error, but by ambiguous grammar. The only solution which eliminates these bugs, is to remove the ambiguities and use a Context-free grammar.

Also I had looked at the recursive descent algorithms option and rejected it objectively.

The speedup in development time from not finding ambiguities will not make ambiguities disappear, because the grammar would still be ambiguous otherwise (backtracing makes a grammar ambiguous except in rare cases), and ambiguity results in semantic inconsistencies in the language, which get borne out as needless programming bugs that waste the hours of every programmer using the language. I have numerous examples of resolved issues at my Google code tracker for Copute.

So that speed up in development effort incurs a cost that is going to paid (probably more excruciatingly) down the line.

http://members.cox.net/slkpg/documentation.html#SLK_FAQ

In the development of Copute’s grammar, I found critical ambiguities that would have not been evident if I had gone with parser combinators (aka recursive descent algorithms). The tsuris I encountered in resolving ambiguities was due to incorrect grammar.

Also they will never be as faster, because for the k lookahead conflicts, they follow unnecessary paths, because the global optimization (look ahead tables) was not done.

I don’t see what is the benefit? Perhaps it is just that the LL(k) parser generation tools are not written in good functional programming style in modern languages, thus making them difficult to adapt to and bootstrap in your new language.

GLR is interesting, but it has some fairly serious flaws. For example, despite Tomita’s claims, the algorithm is not O(n^3) in the worst case. This grammar in particular is O(n^4) for all valid input:

S ::= S S
    | S S S
    | b

Also, GLR is not fully generalized. There are grammars for which GLR (as with any shift-reduce parsing technique) is undefined:

A ::= B A a
    | a

B ::= \epsilon

Granted, most GLR parser generators will transform the above grammar into something which is actually usable within the constraints of the algorithm, but it doesn’t change the fact that GLR is not entirely what it claims to be.

Fortunately, there are algorithms which are fully-general and which attain cubic asymptotic bounds without absurd memory usage. For example, GLL (Generalized LL) is one such technique presented at LDTA 2009. It’s basically just recursive-descent, except that it can handle multiple simultaneous parse trails. And, as with recursive-descent, it is extremely amenable to representation within a functional, composable framework (like parser combinators). In other words, you get all of the benefits of a true, generalized parsing algorithm, cubic performance in the worst case with linear performance on most grammars, all within the easy-to-use framework of parser combinators. Share and enjoy: http://github.com/djspiewak/gll-combinators

I’ve stumbled across your blog. I just want to say thank you, you have a great writing style and the content is hugely informative. I’m trying to learn Scala better and because the language is so grand in scope and capability it can be hard getting started. I know how much time it takes to write quality material. Anyways, thanks again.