* Python, being interpreted, makes a nicer language in which to make an
EDSL for this.
i'm not sure i buy that, but if there was truth in it, that ought to
change!-) nothing against python itself, but i thought the aim was to
get rid of dependencies, such as perl, rather than add them.
You might well argue that Haskell *should* be the right tool for writing
the testsuite driver, and I couldn't disagree. But it's not the right tool
at the moment, which is why I used Python.
i thought it had to be something like this, but it would be nice if there
was a list somewhere of test situations for which you found haskell
currently inadequate. then we could look at that list and see what to
do about it, case by case. perhaps after the release&conferences?
The testsuite is an EDSL, as Ian pointed out. But you really don't want to
have to compile the test descriptions against the testsuite driver code
each time you change one, so you have to use the GHC API somehow.
Unfortunately this is just way harder than just using Python's execFile().
Try it and let me know how you get on!
"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. and there's runhaskell and hunit to start with
(we did use hunit for HaRe; not that our way of using it was elegant,
and my own first attempt was in perl, but the haskell version did the
job). Ian's argument about avoiding ghc dependencies in the non-ghc
parts of the testsuite is good, but i don't see why the ghc api should
be needed? after all, there's a python solution, so are the portable
parts of the haskell libraries too limited to support a testsuite driver
with the features needed here?
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?
thanks,
claus
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
