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).
that esdl could be done with very little extra syntax. how about
-- All.hs
import TestLib
main = runTests
[ test "ghci001" normal ghci_script ["ghci001.script"]
, ..
, test "ghci014" (reqlib "QuickCheck") ghci_script ["ghci014.script"]
, ..
]
then "runhaskell -i<testlibdir> All.hs". you could even prepend the
common source prefix programmatically, giving roughly the same
syntax as in all.T files, and the same flexibility as in testlib.py. you
couldn't test for the name of functions like 'ghci_script', but you
could ask such functions to identify themselves when needed.
perhaps this is all quite academic, given that we're not talking
about use requirements (such as perl/gcc), but about build
requirements (of which there are rather a few anyway). but
even there, the build avoids using bash features in favour of sh
alone, for instance.
anyway, i'm not campaining for change in the ghc testsuite,
just wanted to see what i could learn from your experience
here for the next time i've got to write a testsuite for a haskell
project!-)
claus
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
