pacc logo

More on Errors

In the last article, I was looking at how to handle “semantic errors”, such as [z-a]. As a simplified test case, I'd been playing with this grammar:

S ← a:Letter b:Letter ( &{ a < b } / &{ fail("invalid range") } )  → { "yes" }
Letter :: char ← [a-z] { ref_0(ref()) }

I have a proof-of-concept implementation of fail() that makes this work, and I'd suggested that we might add some syntactic sugar to make this cleaner. Well, I think this is rather sweet:

S ← a:Letter b:Letter &{ a < b || fail("invalid range") } → { "yes" }

I don't know why it took me quite so long to hit upon that. Anyway, so what's really needed is to expose fail() properly. Hmm... this is harder than I thought. The proof-of-concept implementation calls exit(), but that's not what we want to do, we just want to return early from the parser. But return and even goto are statements, not expressions, so even doing nasty tricks with macros I don't see how fail() can easily cause an early exit from the parser.

I suppose fail() could set a flag in the parser object, that we test often in the engine. So I did a proof-of-concept implementation of that.

And on further reflection... yeuch! This whole tangent is misgiven. The “problem” I'm trying to solve is that if I use a semantic guard to reject [z-a] as a character range, my grammar will instead parse it as a 3-character class, the same as [-az]. But this is a bug in the grammar: the alternative interpretation is simply wrong. And if fixing that bug also means that we don't interpret [a-m-n-z] as the same range as [-a-z], well, at least that will match regular expressions.

This is all completed now, and available from the git repo:

git clone git://paccrat.org/pacc

Last updated: 2015-05-24 19:45:27 UTC

Donate

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

News

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

feed