igloo at earth.li
Wed Sep 12 17:57:54 EDT 2007
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
(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
> 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
More information about the Cvs-ghc