pacc logo


Knocking off the last few items on the todo list. One was:

  • command line option to enable tracing

I haven't quite done this. Instead, there is a new macro PACC_CAN_TRACE, either in the .h file if -d was specified, otherwise at the top of the .c file. Tracing code is prefixed with PACC_TRACE which expands to:

if (PACC_CAN_TRACE && PACC_SYM(trace))

Thus if PACC_CAN_TRACE is 0, the conditional is a compile-time constant zero, and the compiler will (hopefully!) optimize away the test and the code it protects. If PACC_CAN_TRACE is 1, then the trace code will be executed if pacc_trace is also 1: this can be set by the code calling the parser in whatever way it wants.

I also changed the Instr code (which reports on hash chain statistics) to use the PACC_TRACE macro instead, as there was really just one stage of development where it was helpful to separate the two.

Another item on the list is to move all names into the namespaces I am claiming: pacc, _pacc, PACC, and ref. (Originally pacc was to be used for names that the pacc user might have occasion to use, and _pacc was for purely internal names, although I haven't been entirly consistent about this.) This includes both external names, and names which are in scope when user code copied from the pacc grammar is being executed, which makes this quite burdensome. For example, col which identifies the current character in the input is used in almost every line of the generated parser. Not only is pacc_col verbose, but by the time every identifier starts with pacc_ the code will be extremely hard for a human to read.

So I'm thinking that, whilst it is right to use the pacc prefix for external names, perhaps I could just use an underscore prefix for names static to the parser.

That's now completed. Some variable names could be better chosen, and I think one or two could be eliminated, or have their scope tightened (for example, I'm almost _pacc_any_i could be scoped inside the couple of loops that use it). But those can wait for another release.

Last updated: 2015-05-24 19:45:21 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