pacc logo

Happy New Year!

Unfortunately I've been incredibly busy recently, first moving home yet again (hopefully stable for a little bit now) and then dealing with a family bereavement. However, that's largely dealt with now, and 2013 promises to be a fantastic year for pacc!

The last thing I was working on before the hiatus was a new error interface. When there is a syntax error detected by pacc itself, it reports the line and column number where it found the error, as well as a clue to what the error was. However, sometimes we might not detect an error in the grammar itself, but in a semantic action.

For example, consider character classes. A range such as [a-z] is valid, whereas a range such as [z-a] is not, but the difference is not one that can be expressed in the PEG itself. (In this particular case, one could argue that the second range has the same meaning as the first. I don't think that's a good argument in any case, and anyway the general idea of nearly syntactic errors is valid.)

So we need an interface to report errors with line and column numbers. Or do we? If semantic guards were a bit cleverer, and in particular allowed us to specify messages, maybe we don't need this feature. The current definition of a character range looks more or less like this (I've omitted some casts that keep the compiler quiet):

    ← a:CChar "-" b:CChar { s_range2(a, b) }
    / a:CChar { s_range1(a) }

Hmmm... now there's another problem here. If we add a semantic guard to the first alternative, I was thinking along these lines:

... a:CChar "-" b:CChar &{ b > a } { s_range2(a, b) } / ...

then a class like [z-a] will parse the same as [-az], in other words a class that matches 3 characters. That's definitely not what we want. There might be ways around that, but I rather like the simplicity of the PEG definition of a class: a hyphen means a hyphen wherever it can't be part of a range. This does mean that [a-m-z] means the same as [a-mz-], whereas regular expressions treat it as an error.

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


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