PEGs can sometimes be pretty unintuitive. For example, consider the grammar ("a" / "aa") "a" in a traditional BNF setting, this grammar could match the st

PEGs can sometimes be pretty unintuitive. For example, consider the grammar ("a" / "aa") "a" in a traditional BNF setting, this grammar could match the string aa or the string aaa. However, this PEG will only accept the string aa, and cannot match the string aaa. (This is because of how backtracking works in PEGs—or, more precisely, how it doesn't work. With the input string aaa, we'll first try to match ("a" / "aa") against the input in a left-biased way, which succeeds because "a" matches. Then we'll try to match the second expression—"a"—which also matches. Now we are done with the grammar but still have the last a in the input, so the grammar fails. There were untried alternatives, but they only appeared in earlier parts of the grammar which had already 'succeeded', so we never go back and try them.) Additionally, both LR and PEG parsers take linear time to parse a given input, but PEG/packrat parsing has much larger constant factors. On small examples, this might not be a big deal (what's 0.2 seconds compared to 0.02 seconds when loading a file?) but when doing large amounts of parsing it can definitely be a minus on the PEG/Packrat side.