pacc logo


So, it's time I tackled feeding. This is, I believe, a unique feature of pacc, and makes it possible to use packrat parsing on the command line. I'm a bit hesitant to dive into this one: I had a proof-of-concept for peg / leg a couple of years ago, but I actually don't have that to hand at the moment. The concept isn't a tricky one. But the details will inevitably be tedious.

Let's start with the command line. --feed foo turns on feeding, and foo() is the feeder function (I don't think we'll allow a default feeder). --feed-rule x gives the name of the rule that appears at feed points; it defaults to __ (two underscores). That's easy enough.

I think I want to make another proof-of-concept in pacc this time. Let's take test/pacc/baf4.pacc as a starting point, and add feed markers. Hmm. Consider this pair of rules:

__ ← ("\n" / _)*
_ ← [ \t]*

pacc says left recursion in rule `__:*:0'. And it's right, up to a point (future work: report the error more meaningfully in terms of the user's sugar). The derived rules read:

__:*:0  ←  __:1:0  __:*:0  /  ε
__:1:0  ←  "\n" / _

So the desugared rule __:1:0, which matches a single instance of the subject of the * operator, may make no progress, because _ may make no progress. And so we may indeed left-recurse into __:*:0. Yeah, OK, pacc is right, I'm wrong. I love it when that happens! What we want here is:

__ ← ("\n" _)*

Hmm again. This grammar, or even the unmodified one, is apparently happy to parse 2 + (with a value of 2). How can that be: it includes an end-of-input marker? There's a much simpler eof test in test/pacc/not1.pacc, and that works as expected. It's unfortunately not all that easy to see how pacc parsed an input unless it built a syntax tree. Better try and get a smaller example that fails in the same way. Aha! Once again, pacc is right, and I'm wrong. We had this rule:

Decimal ← Digit* Space { atoi(ref_ptr(ref())) }

which allows an "empty" Decimal. Obviously it should be Digit+, and with that change it behaves as expected.

Last updated: 2015-05-24 19:45:25 UTC


Porting and packaging

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...

Release relief

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...

See more news articles