pacc logo

New Error Interface

I have been looking at how user-supplied code can report “semantic errors” in the input. For example, when pacc.pacc sees a purported character class such as [z-a] we want to test that in s_range2() and report it as an invalid range, along with the location of the error.

The first phase was to split the old error reporting function YY_error() into two. The replacement YY_error() function generates the specific error we encountered (such as expected Defns, or end-of-input) and hands that to a new YY_pos() function which prepends the position of the error (such as parse.pacc:5:7). The error is now returned as a char *, for the outer program to use how it wishes (such as outputting to stderr).

So now we can use YY_pos() to output a semantic error and its location. Except... darn, we can't. Following our usual object-like style, the first argument to YY_pos() is the parser object, but that's not known to s_range2(). In code spliced in from the grammar, it is in scope as _pacc, but so far we've avoided mentioning that. Still, at present I don't see a better way to do it than to pass _pacc in as an extra argument to s_range2().

Just now though, I've got into a confusing mess where pacc.h and syntax.h depend on each other, and I'm too tired to sort it out.

OK, fixed that one by judicious use of void *, but I've run into a minor hitch and a major snag. The minor hitch is that just now we call fatal() and so output pacc: fatal: parse.pacc:x:y: invalid range. We don't need that much decoration!

The major snag, though, is that x:y always references the end of the file! Of course, because we don't evaluate anything, except semantic guards, till the entire grammar is parsed.

So after some thought, I have devised a way that we can handle this in semantic guards. Something like this:

CRange ← a:CChar "-" b:CChar ( &{ a < b } / &{ fail("invalid range") } )

Perhaps later we can add syntactic sugar to this, but first let's see if it works at all. Yes, that's fine. Needs some tidying up, but I think we have a goer!

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