simonmarhaskell at gmail.com
Thu Sep 13 03:57:20 EDT 2007
Ian Lynagh wrote:
> 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.
Exactly. Replicating the testsuite as it currently is -- an EDSL -- in
Haskell, would be hard and the results would be unsatisfactory I think. As
you say, if you switch to data rather than code for the test descriptions,
then you need a data type, a parser, and an interpreter, all of which needs
extending every time you need to do something new (which happens quite a lot).
FWIW, the predecessor to the current testsuite was a home-grown language
interpreter written in Haskell. You can probably still find it in the
darcs history. That approach turned out to be unsatisfactory for various
More information about the Cvs-ghc