Knocking off the last few items on the todo list. One was:
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
One thing that pacc has lacked all the way along is users. It turns out to be really hard to write decent code without those darned users probing the dark corners. Read More...
I finally got round to implementing a simple but highly useful feature in the language, which I'm calling default expressions. It's probably simplest to explain by showing the test case: Read More...