ambiguity is useful for error recovery/error detection. also, some languages have ambiguity in their syntax (ML). I don't buy the 'optimization' argument. there is no reason we cannot have our cake and eat it - ambiguity and incremental parsing.
I think parser-generators are unpopular because people would prefer to just write code, rather than compile something else to automatically generated code that is nigh on unreadable.
I think the popularity of regexes is due in part to the ease of which they can be embedded or used within the host language - either with syntactic sugar, or simply as a library.
combinators (parsec especially) hit a sweet spot of being able to write code that handles parsing succinctly, without having to conflate your build or auto-generate source.
i'd really prefer a library I can load and manipulate the grammar from, over yet another syntax and compiler in my tool chain.
(ps. (i'm saddened by the lack of left recursion support in gazelle))
regular expressions (ala cs) are equiv to finite state machines. regular expressions can't count or match ()'s. ragel allows you to mix in code within the state machine, so it is actually far, far more powerful than a finite state machine.
in http, handling things like 'Content-Length: %d' and then reading a subsequent length is a little harder. as is handling transfer-chunked encoding. http is quite fiendish in places :-)
these are 'data dependent' - the parse stream contains information (i.e length) on the subsequent tokens - although some regexps have back references, these aren't common place in parsing tools/formalisms like LR,LL,LALR,CFG or PEGs.
my point is simply that a lot of the parsing drama of late has revolved around the simple task of parsing a language, rather than parsing network protocols.
there is a larger class of parsing problems that are still to be tackled.
I can't remember off hand if it dealt with nullable terms or hidden left recursion properly either.
don't get me wrong: I like the earley parser :-) I just think the original paper has some omissions and the treatment of earley parsing in 'parsing techniques 2nd ed' is thorough and includes substantial references and explanations of further work.
and while i'm here - the original earley paper is full of bugs.for a modern treatment you may find aycock & horspool's work on 'practical earley parsing' interesting, as well as the work on the Marpa Parser in perl.
to me: the earley parser and the packrat parser are similar in nature - they are both chart parsers. one is depth first, one is breadth first.
my question: can you engineer an earley parser that supports ordered choice and exploits this to avoid broadening the search too early -- ie can earley parsers support PEGs
I think it is possible and when i'm not drowning in my startup work i'd like to take a longer look at it.
i've tried to use some ideas from the aycock and the aretz variants of the earley parser - avoiding lists of earley items at a character - instead storing the reductions/completions seperately from the scanning items,
and using a driver rather than the predictor/completor loop (still need to add nullable support...)
It has several bad properties too. The algorithm they outline is exponential.
The challenge to make it run in cubic time will certainly turn it into a GLR or an Earley parser. (They can be formed from each other)
To me: it is just another way of looking at Dotted LR-Items used within earley parser. Earley parsers keep a state made up of grammar rules with a dot indicating where in the rule the parser is at.
(I wrote an earley recognizer that uses a derivative style interface to grammar rules.)
It has novelty, and some utility but it is not the holy grail you are looking for.
I have a couple of loosely connected points and links:
You want to buy 'Parsing Techniques 2nd Ed' -- this book is fantastic and will give you the understanding and clarity you seek. It is wonderfully comprehensive.
And yes most of my left recursion fetish would be covered by an operator precedence parser/left corner parser