On Wed, Sep 12, 2007 at 08:43:51PM +0100, Claus Reinke wrote: > > "use the source"?-) test descriptions sound like data+read, with a > test driver to be compiled once when the format changes, not when > the description changes.
Right, if you don't go for an EDSL then interpreted languages lose their advantage. The problem then is that you have to account for all the special cases in the driver, ideally in a non-adhoc way, and such that the same driver can be used by other (even non-Haskell) projects. I think it is possible to do this well, but it is not a 5 minute task. OTTOMH, special cases are things like * Normally the expected result is X, but on powerpc/BSD with GHC 6.6.1, the expected result is Y * The expected result is X, unless the QuickCheck package is available, in which case it is Y (or "Do not run this test if QuickCheck is not available") (and personally I would use a defined format rather than Read, so drivers can easily be written in other languages and interoperate correctly. Also, it would probably allow a less verbose format). > and there's runhaskell runghc isn't portable, and we can't assume that anything else is installed. > and hunit hunit doesn't really buy us much. We still have to do all the "compile the file, see if it gave the right error message" etc stuff ourselves. > parts of the testsuite is good, but i don't see why the ghc api should > be needed? Simon was talking about loading an all.T file as a Haskell file, i.e. going the EDSL route, I think. > if you don't get around to making that list of "haskell inadequacies > for testsuites",-) could you perhaps point me to one or two specific > test cases that i should look at as examples of things that would > be difficult to do in haskell? No individual case is hard, the hard bit is coping with all cases cleanly. Thanks Ian _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
