One of the few blockers left on the todo list is “command line option to enable tracing”. That's clear enough, but to make that work, we really want to define a macro that will switch tracing on or off in pacc.h. And that's fine, except... pacc.c doesn't actually include pacc.h! My argument was that, since both files are automatically created, we don't need the customary consistency check between .c and .h.
I was never very convinced by that argument, but it is a trifle awkward to include the header file, as its name is not constant, so it will need to be patched into the template output.
Another blocker is “expose ability to alter prefix”, which is obviously related, since currently the prefix is the only non-constant item in the template output. The prefix is represented by YY in the template, and currently is always pacc or pacc_feed.
Stage one is to add a new command-line argument: -n NAME (or --name=NAME). This defaults to the input filename less its .pacc suffix. Now the output filename defaults to NAME.c (but can of course be specified with -o), and the defines filename defaults to NAME.h (if enabled with -d and not explicitly given). This name is now pasted into the root node of the AST, but I haven't done anything with it yet.
Hmm. But there's an awful snag here: NAME must be a valid C identifier, so what do we do if the input filename is test/one.pacc or one-two.pacc? Answer, nothing: the idea of deriving NAME from the input filename is simply bogus. NAME can simply be pacc; in the rare cases where the user wants more than one parser in a program, she will have to devise distinct names for the parsers.
A thought: why don't we simply have a single macro like this:
#define PACC_NAME whatever
and use token-pasting? That's at least worth experimenting with. And it works very nicely indeed. I was rather proud of the sed script that turned pacc.tmpl into the C code to write a parser, but the tricky part of that has now gone, to be replaced by some trick C preprocessor macros.
So the first thing is to tidy up so that pacc.c actually includes a pacc-created pacc.h. One thing that strikes me is that currently we include the preamble in both pacc.c and pacc.h. We need this in pacc itself, because it is the preamble that includes syntax.h, which we need for the types of yy_wrap() etc. However, in general, this probably isn't right. I think we will need eventually to have two preambles, which is going to be a complicated change.
In the end, though, I have gone the other way. The problem is that, since pacc compiles itself, any dependency on pacc.h ends up being circular. So it's simpler just to stuff an extern declaration of pacc_wrap() at the top of main.c. However, this does mean that pacc -d isn't tested any more. I think I need to cook up some more realistic examples.
Last updated: 2015-05-24 19:45:22 UTC
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...
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...