pacc logo

State of the union

So the next "blocker" I want to tackle on the list is to tidy up the union so it contains only one instance of each type--it would be nice to support void at this point, but we'll see.

I suppose you could argue that this isn't really a blocker, since the current code works, and doesn't seem to run into any compiler limitations. It's just really ugly.

This is one of those cases where "n is usually small" - for example, pacc.pacc has just 5 different types (and will eventually add void, but that doesn't come into the union anyway). It's hard to imagine a grammar that would use many more. So we don't need any clever data structures--a simple vector with linear search will be perfectly adequate.

Done. What's next? I was thinking this wouldn't be a bad time to do void, since we're playing with types, but that's a "later" rather than a "blocker". I suppose detecting left recursion would be a good one. I've read a lot about left-recursion, and have decided to pin my colours to the masts of Dale Schumacher, who wrote Left Recursion Considered Harmful (he didn't quite call it that) and Ian Piumarta, who's peg / leg recursive-descent PEG parsers for C inspired me to start pacc.

Obviously, there's a huge advantage in not trying to handle left-recursion (other than to detect it), which is that I don't have to implement anything! Anyway, I'm supposed to be using test-based development, so let's start with a left-recursive test-case or two. Easy, and either direct or indirect left-recursion loops. (In fact, they run out of memory very quickly, which is a bit disturbing. Hmm... let's quickly look at that with a debugger. OK, well one thing that's going wrong is in int l = 2 * (p->stack_alloc - p->stack) + s; we only have 31 bits to play with. Obviously that should be a size_t. That's better! We now run for about a minute and grow to over 10G before the inevitable grisly death.)

OK so that's all done. Huge thanks again to Ian for idea liberation.

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