Writing a pre-processor

Ovid on 2005-06-19T20:01:51

It's very unusual, but my macro system for Prolog is a Prolog preprocessor written in Perl for AI::Prolog. Basically, whenever a Prolog snippet is passed to AI::Prolog, the preprocessor will search for unusual syntactical bits (such as math) and rewrite them in an internal form which the current parser already understands. In other words, as mentioned earlier, it's a source filter for a language embedded in Perl.

I'm am just getting the barest glimmering of an idea of what happens when someone really implements a language. I'm already up to about 86 tests just for the pre-processor and there's a long way to go. Part of what makes this fascinating is my realization, after a typo led to an unexpected success, that I needed far better test coverage on this than I normally do. And I don't just mean "test every line of code." Using a regex once counts as code coverage for that line. It hardly counts as coverage for the regex. I'm having to really think hard to come up with reasonable counter-examples without providing the infinite number of negatives that each regex can have.

Currently the full regex comes to 88 lines when printed out.


branch coverage for a regex

merlyn on 2005-06-19T22:17:37

Now that'd be an interesting idea. Using the regex modules in the CPAN, pull apart a regex, and insert tracing steps as code blocks into it, to make sure your tests shook out all the braches. Devel::Regex::Cover, anyone?