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


Support the development of pacc with a donation! We accept donations in BitCoin or via PayPal who handle almost any other form of payment.


A new bug

Unfortunately, there are too many projects in this world, and pacc has been neglected for too long. However, I have been looking at one of those other projects recently, in fact, the one that convinced me I needed to write pacc in the first place! A new bug has turned up. (Hooray?) Read More...

Tying the loop tighter

If it seems to have gone quiet around here recently, that's only partly because it's summer, and the lure of the outdoors is stronger than staying in with my head in a chunk of code. I have been gnawing away at a major subproject: converting a real language based on yacc over to pacc. This has been quite an eye-opener! Read More...

See more news articles