pacc grammars are now anchored on the right. That is, to be considered a successful parse, the start rule must match the entire input, and not just a prefix of it.
I contemplated this change a while ago, and decided against it on the grounds that other PEG parsers don't anchor on the right. However, we're not endeavouring to be compatible with any other PEG parser, so in this case I think it's more important to be Right than Popular. Why do I think right-anchoring is Right?
So it's done. Unfortunately, this introduces 43 new FAILs: they're almost all of the “different error message” variety, but they'll have to be looked at... Actually, although some are to do with right-anchoring, but mostly the differences are caused by changing an occurrence of col to rule_col when an error is flagged for a rule that has made no progress. For example, the test bad/rep0.pacc consists of the “rule” S ← .**. This used to generate the error expected NameStart:c:0, which is fairly meaningless, desugared, and was one character past where it should have been to boot!
Now it points to the second * with the error expected Defns, or end-of-input, which is definitely an improvement. (This stuff still isn't right, though: there's a whole bunch of other things — any matcher, or → for example — that could come after S ← .*. Still, we're making progress.)
All fixed up, back to the expected 4 FAILs.
Last updated: 2015-05-24 19:45:28 UTC
One thing pacc needs is more users. And, perhaps, one way to get more users is to reduce the friction in getting started with pacc. An obvious lubricant is packaging. Read More...
Looking at _pacc_coords(), I noticed that it seemed to have the same realloc() bug that I'd just fixed in _pacc_result(). However, the "list of arrays" trick really wasn't going to work here. Read More...