> I'd say PEGs are easier to write as they're unambiguous. While that is technically true, it doesn't solve the actual issue of ambiguity, it just defines it a

> I'd say PEGs are easier to write as they're unambiguous. While that is technically true, it doesn't solve the actual issue of ambiguity, it just defines it away. If you have a case in your language where two syntax rules both match, it's confusing to users because you have to arbitrarily decide that one of them is correct. The best-known example of this is the dangling else ambiguity: https://en.wikipedia.org/wiki/Dangling_else https://en.wikipedia.org/wiki/Dangling_else Sure, PEGs by definition are unambiguous, but only because they arbitrarily decide that the first option always "wins." The language itself might still be ambiguous, but you aren't aware of it because the parser always chooses the first option. Put another way, with PEGs you never know if: a -> b / c; is equivalent to: a -> c / b; You also don't know if there are rules that are entirely unreachable. Besides this, packrat parsing (the PEG parsing algorithm) is significantly more expensive than LR/LR parsing. Packrat parsing takes O(input length) memory -- significantly more than the O(tree depth) space of LL/LR. I talk more about these issues in my blog article: http://blog.reverberate.org/2013/09/ll-and-lr-in-context-why-parsing-tools.html http://blog.reverberate.org/2013/09/ll-and-lr-in-context-why...