Hi
I actually think that something like this should be preserved. I can imagine several reasons for having flags of this kind. Platform-specific flags are an obvious one. Another would be to distinguish QuickCheck, HUnit and FastCheck tests, as well as tests that take no arguments. Currently Neil treats these as QuickCheck tests, but this (unless I'm mistaken) will result in each one being called 100 times, which shouldn't be necessary.
Nope, I treat them as properties and assert them once. The algorithm I use is that things which are single letters are free variables, and single letter followed by 's' - if a property has no free variables its an assertion and only gets executed once.
So I suggest that we look for lines of the form
-- > q: reverse (xs ++ ys) == -- > (reverse ys ++ reverse xs) -- > u: reverse "foobar" == "raboof" -- > u: null $ reverse []
I would have thought:
-- > forall xs ys . reverse (xs ++ ys) == (reverse ys ++ reverse xs) -- > reverse "foobar" == "raboof" -- > null $ reverse []
I suspect the quantification will be needed explicitly so you can tell between reverse the free variable and reverse the function.
Incidentally, how does the test extractor handle arguments? Does it parse the code for variables? If so then could we have a line to declare argument types for properties where they can't be inferred? Something like:
-- > t: xs, ys :: [Int] -- > t: str :: String
I have a scheme where some set of letters refers to file names, and some to other stuff. I also wrap things as well, to get a different quickcheck generator - i.e. newtype CheckFilePath = CheckFilePath FilePath, then unwrap it before doing the actual call. There are lots of design decisions - the best thing would be to set up a wiki page as the theoretical documentation of the tool, then once the manual is stable you can write the tool. Feel free to take any or none of my tool as the starting point. Thanks Neil