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 <[email protected]> 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 > [email protected] > http://www.haskell.org/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
