Choices, choices. The first one is to use unit tests. Look at the grammar and make sure the obvious stuff fails or succeeds. "a + b", "a :+ b", etc. You can do this at the Haskell level with parser objects. Next you can write small samples to test things the unit tests did not. Compare the output to known results. There are numerous examples of this in the open source world you can either reuse or crib from. Personally I think QuickCheck is more work than it is worth here. On Jun 11, 2011, at 8:18, Paul Johnson wrote:

On 11/06/11 14:10, Andrew Coppin wrote:

...

OK, so suppose you sit down and write a complicated string parser. Now how do you test that it works correctly?

If you have a function that turns a parse tree back into text again, you can try verifying that a round-trip is the identity function. Except perhaps sometimes it isn't. Perhaps a given expression has more than one equivalent representation. A round-trip from string and back again is even less likely to be stable.

So what's the best way to attack this problem?

_

If your parse tree has a "show" instance (or better yet, a pretty-print function) then you can generate random parse trees, print them, and then show that the parse returns an equal tree.

However if you want to have useful error messages or a wider range of representations than just those generated by "show" then you will need to write a QuickCheck variant on the "show" function that emits all these variations, which is likely to be rather more work.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Sat, 11 Jun 2011 10:34:47 -0700 Alexander Solla wrote:

On Sat, Jun 11, 2011 at 10:06 AM, Sean Perry wrote:

...

Choices, choices.

The first one is to use unit tests. Look at the grammar and make sure the obvious stuff fails or succeeds. "a + b", "a :+ b", etc. You can do this at the Haskell level with parser objects.

Next you can write small samples to test things the unit tests did not. Compare the output to known results. There are numerous examples of this in the open source world you can either reuse or crib from.

Don't just test the "obvious" things. If the parse tree is truly a tree, it is an initial algebra and amenable to case analysis as an initial algebra. In other words, you can do a proof by induction, just by checking all the base cases.

Wouldn't also be reasonable for the test cases to be generated from the grammar automagically ? Seems much more useful than attempting to do it by hand. Seems like something which would have already been done, i.e. there's already a tool out there that does that ? Brian