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
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.
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
reasons too.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
