I tried the following from the paper QuickCheck Testing for fun and profit.
prop_revApp xs ys = reverse (xs ++ ys) == reverse xs ++ reverse ys
and it passed even though it should not have.
I ran verboseCheck and I see that it is only checking lists of units, i.e.:
Passed:
[(),(),(),(),(),(),(),(),(),(),(),(),(),()]
I was wondering why this was.
I am aware I can fix it by defining the type of the property but was wondering if this was necessary or I was missing something.
The prop_revApp function is quite generic:
*Main> :t prop_revApp
prop_revApp :: Eq a => [a] -> [a] -> Bool
If you're just loading the code in GHCi, and run it, yes, indeed, the property passes:
*Main> quickCheck prop_revApp
+++ OK, passed 100 tests.
This is because GHCi comes with a set of preferred defaults. For convenience, it'll try to use the simplest type it can.
It doesn't get much simpler than (), and since () has an Eq instance, it picks that.
If, on the other hand, you actually try to write and compile some properties, the code doesn't compile:
import Test.Framework (defaultMain, testGroup)
import Test.Framework.Providers.QuickCheck2 (testProperty)
import Test.QuickCheck
main :: IO ()
main = defaultMain tests
prop_revApp xs ys = reverse (xs ++ ys) == reverse xs ++ reverse ys
tests = [
testGroup "Example" [
testProperty "prop_revApp" prop_revApp
]
]
If you try to run these tests with stack test, you'll get a compiler error:
test\Spec.hs:11:17: error:
* Ambiguous type variable `a0' arising from a use of `testProperty'
prevents the constraint `(Arbitrary a0)' from being solved.
Probable fix: use a type annotation to specify what `a0' should be.
These potential instances exist:
instance (Arbitrary a, Arbitrary b) => Arbitrary (Either a b)
-- Defined in `Test.QuickCheck.Arbitrary'
instance Arbitrary Ordering
-- Defined in `Test.QuickCheck.Arbitrary'
instance Arbitrary Integer
-- Defined in `Test.QuickCheck.Arbitrary'
...plus 19 others
...plus 61 instances involving out-of-scope types
(use -fprint-potential-instances to see them all)
* In the expression: testProperty "prop_revApp" prop_revApp
In the second argument of `testGroup', namely
`[testProperty "prop_revApp" prop_revApp]'
In the expression:
testGroup "Example" [testProperty "prop_revApp" prop_revApp]
|
11 | testProperty "prop_revApp" prop_revApp
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You'll have to give the property a more specific type; e.g.
tests = [
testGroup "Example" [
testProperty "prop_revApp" (prop_revApp :: [Int] -> [Int] -> Bool)
]
]
Now the test compiles, but fails:
$ stack test
Q56101904-0.1.0.0: test (suite: Q56101904-test)
Example:
prop_revApp: [Failed]
*** Failed! Falsifiable (after 3 tests and 3 shrinks):
[1]
[0]
(used seed -7398729956129639050)
Properties Total
Passed 0 0
Failed 1 1
Total 1 1
Q56101904-0.1.0.0: Test suite Q56101904-test failed
Test suite failure for package Q56101904-0.1.0.0
Q56101904-test: exited with: ExitFailure 1
Logs printed to console
Related
Haskell. Matching pattern Problem. Cannot put in IO value of function with empty list
print $ note1 []
failing to compile, but works fine in ghci ?!
Also the print $ note1 [1] works fine and compiles fine too. The problem only with empty list:
print $ note1 []
(N.B. I am new in Haskell)
I
have a matching pattern function
note1 :: (Show a) => [a] -> String
note1 [] = "Empty"
note1 (x:[]) = "One"
But print $ note1 [] fails to compile, but perfectly works in ghci interpreter?!
I am using stack 2.3.1 and ghc 8.8.3 on MacOS.
This is the compilation error produced by compiler.
/Users/admin1/Haskell/PROJECTS/orig1/src/Lib.hs:18:13: error:
• Ambiguous type variable ‘a0’ arising from a use of ‘note1’
prevents the constraint ‘(Show a0)’ from being solved.
Probable fix: use a type annotation to specify what ‘a0’ should be.
These potential instances exist:
instance Show Ordering -- Defined in ‘GHC.Show’
instance Show Integer -- Defined in ‘GHC.Show’
instance Show a => Show (Maybe a) -- Defined in ‘GHC.Show’
...plus 22 others
...plus 15 instances involving out-of-scope types
(use -fprint-potential-instances to see them all)
• In the second argument of ‘($)’, namely ‘note1 []’
In a stmt of a 'do' block: print $ note1 []
In the expression:
do putStrLn "someFunc"
putStrLn $ show (1)
putStrLn $ show $ length ("a" :: String)
putStrLn $ show (length' "a")
.... |
18 | print $ note1 []
The problem is the (unnecessary, in this case) Show a constraint on note1. Here's what happens. When GHC is typechecking print $ note1 [], it needs to work out which Show instance to use with note1. That's typically inferred from the type of elements in the list that it's passed. But the list it's passed ... doesn't have any elements. So the typechecker has no particular way to choose an instance, and just gives up. The reason this works in GHCi is that GHCi, by default, enables the ExtendedDefaultRules language extension, which expands the type defaulting rules. So instead of throwing up its hands, the type checker picks the type () for elements of the list, and everything works. Something sort of similar is going on when you use [1]. In that case, the standard defaulting rule comes into play: numeric types default to Integer, so the typechecker picks that type.
How should you fix this? You could manually write
print $ note1 ([] :: [()])
to make your code compile, but if that's your real code, you'd be much better off removing the unnecessary constraint:
note1 :: [a] -> String
note1 [] = "Empty"
note1 (x:[]) = "One"
As a side note, since you don't use the x variable, it's best to make that fact explicit by either using the special _ pattern:
note1 :: [a] -> String
note1 [] = "Empty"
note1 (_:[]) = "One"
or prefixing the variable name with an underscore:
note1 :: [a] -> String
note1 [] = "Empty"
note1 (_x:[]) = "One"
This indicates, both to other programmers (such as yourself a few hours later) and the compiler, that you are intentionally not using that value.
Additionally, you can (and probably should) use list syntax to clarify the second pattern:
note1 [_] = "One"
Finally, the note1 function has a bit of a problem: if you pass it a list with more than one element, it'll produce a pattern match failure. Whoops! It's usually better to write total functions when you can. When you can't, it's generally best to use an explicit error call to indicate what went wrong. I recommend compiling your code with the -Wall flag to help catch mistakes.
I try to write a quick sort in Haskell and I knew there are many versions out there.
This one is pretty simple for Int type
quickSort1::[Int]->[Int]
quickSort1 [] = []
quickSort1 (x:xs) = [l | l <- xs, l < x] ++ [x] ++ [ r | r <- xs, r > x]
I can print on Main as following
print $ quickSort1 [] -- output []
print $ quickSort1 [2, 1] -- output [1, 2]
I modified the above quickSort1 to "more general" type with (Ord a) instead of Int
quickSort2::(Ord a)=>[a]->Maybe [a]
quickSort2 [] = Nothing
quickSort2 (x:xs) = Just $ [ l | l <- xs, l < x] ++ [x] ++ [ r | r <- xs, r > x]
On my Main, I can run
it works
print $ quickSort2 [2, 1] -- output [1, 2]
I got compiler error when I run following
print $ quickSort2 [] -- got error
Can anyone explain to me what is going on with my new version of quickSort2
I assume you use a file foo.hs and in it
main = print $ quicksort []
quicksort = ... - as defined above in quickSort2
then you get two error messages when you runghc foo.hs
foo.hs:3:8: error:
• Ambiguous type variable ‘a0’ arising from a use of ‘print’
prevents the constraint ‘(Show a0)’ from being solved.
Probable fix: use a type annotation to specify what ‘a0’ should be.
These potential instances exist:
instance Show Ordering -- Defined in ‘GHC.Show’
instance Show Integer -- Defined in ‘GHC.Show’
instance Show a => Show (Maybe a) -- Defined in ‘GHC.Show’
...plus 22 others
...plus 11 instances involving out-of-scope types
(use -fprint-potential-instances to see them all)
• In the expression: print $ quicksort []
In an equation for ‘main’: main = print $ quicksort []
one telling you that ghc cannot tell what Show instance to use and ghc 8 already tells you how to solve this:
add a type annotation (as #duplode already suggested)
main = print $ quicksort ([] :: [Int])
Quite similar but slightly different is the second error message
foo.hs:3:16: error:
• Ambiguous type variable ‘a0’ arising from a use of ‘quicksort’
prevents the constraint ‘(Ord a0)’ from being solved.
Probable fix: use a type annotation to specify what ‘a0’ should be.
These potential instances exist:
instance Ord Ordering -- Defined in ‘GHC.Classes’
instance Ord Integer
-- Defined in ‘integer-gmp-1.0.0.1:GHC.Integer.Type’
instance Ord a => Ord (Maybe a) -- Defined in ‘GHC.Base’
...plus 22 others
...plus five instances involving out-of-scope types
(use -fprint-potential-instances to see them all)
• In the second argument of ‘($)’, namely ‘quicksort []’
In the expression: print $ quicksort []
In an equation for ‘main’: main = print $ quicksort []
Where in the first message the print function demanded a Show instance - here you promised the quicksort to supply a list of orderables - but did not say which to use, so GHC complains about what Ord to use.
Both messages are due to the fact that [] is too polymorphic it could be a list of anything - [Int] is good, but it could also be something like [Int -> Bool] which is neither Showable nor Orderable.
You could as well supply quicksort with something weird like a
newtype HiddenInt = HI Int deriving (Ord) --but not Show
which would work for the quicksort function but not for print.
Side Note
Your quicksort functions need to be recursive in order to really be correct - as I pointed out in my comments - there is a logical problem in your algorithm - be sure to test your functions properly e.g.
import Data.List (sort)
main :: IO ()
main = do print $ "quicksort [10,9..1] == Just (sort [10,9..1]) is: "
++ show $ quicksort ([10,9..1]::Int]) == Just (sort ([10,9..1]::Int]))
print $ "quicksort [5,5,5] == Just (sort [5,5,5]) is: "
++ show $ quicksort ([5,5,5] :: [Int]) == Just (sort ([5,5,5] :: [Int]))
quicksort :: (Ord a) => [a] -> Maybe [a]
quicksort = ...
or if you are interested take a look at QuickCheck - which is a bit more advanced, but a step in the right direction for verifying your algorithms/functions work the way you expect them.
Is there a way to falsify this (wrong) property:
prop :: Eq a => [a] -> Bool
prop xs = reverse xs == xs
When i Use QuickCheck and later VerboseCheck it gives 100 different forms of:
[(),(),(),(),(),(),(),(),(),(),(),(),(),(),()]
Passed:
and the final result is:
+++ OK, passed 100 tests.
It just so happens that
If you try to evaluate that in GHCi, it has to choose a particular instance type of Eq a to use, and with the ExtendedDefaultRules extension normally enabled in GHCi, it chooses ().
For the type (), because it has only one (non-bottom) value, the proposition is actually true.
The simplest fix is to choose (almost) any other type by providing a type annotation:
Prelude Test.QuickCheck> quickCheck (prop :: [Int] -> Bool)
*** Failed! Falsifiable (after 4 tests and 3 shrinks):
[0,1]
I have the following function that is supposed to return the last but one element of a list:
myButLast :: [a] -> a
myButLast [] = error "List has less than one element!"
myButLast [x] = error "List has less than one element!"
myButLast [x,_] = x
myButLast (_:xs) = myButLast xs
It works for all special cases when I load it into ghci, but when I try to test it using HSpec, I get an error when running this spec:
main :: IO ()
main = hspec $ do
describe "myButLast" $ do
-- removed other specs --
it "throws an error when called with a singleton list" $
myButLast [1] `shouldThrow` anyErrorCall
This is the error message:
No instance for (Num (IO a0)) arising from the literal `1'
Possible fix: add an instance declaration for (Num (IO a0))
In the expression: 1
In the first argument of `myButLast', namely `[1]'
In the first argument of `shouldThrow', namely `myButLast [1]'
Interestingly, the compiler does not complain when test myButLast [] instead of myButLast [1], although the results of both expressions are defined exactly the same.
As simon pointed out:
myButLast [1] simply has the wrong type, namely Num a => a, while shouldThrow expects a first argument of type IO a.
So, the more interesting question is:
Why doesn't the compiler complain about the type of myButLast []?
The reason for this is: As the literal [] can also be of type [IO a], the compiler infers the type of myButLast [] to be IO a, because this is the only thing that would be a valid first argument to shouldThrow.
To answer the question behind the question: to write the test, you want to use evaluate:
import Control.Exception.Base
main :: IO ()
main = hspec $ do
describe "myButLast" $ do
it "throws an error when called with a singleton list" $
evaluate (myButLast [1]) `shouldThrow` anyErrorCall
I started doing 99 haskell problems and I was on problem 7 and my unittests were blowing up.
Apparently, it's due to this: http://www.haskell.org/haskellwiki/Monomorphism_restriction
I just wanted to make sure I understood this correctly because I'm kinda confused.
situation 1: func a is defined with no type def or with a non-strict type def and then used once, the compiler has no issues infering the type at compile time.
situation 2: the same func a is used many times in the program, the compiler can't be 100% sure what the type is unless it recomputes the function for the given arguments.
To avoid the computation loss, ghc complains to the programmer that it needs a strict type def on a
to work correctly.
I think in my situation, assertEqual has the type def of
assertEqual :: (Eq a, Show a) => String -> a -> a -> Assertion
I was getting an error when test3 was defined that I interpreted as saying that it had 2 possible types for the return of testcase3 (Show and Eq) and didn't know how to continue.
Does that sound correct or am I completely off?
problem7.hs:
-- # Problem 7
-- Flatten a nested list structure.
import Test.HUnit
-- Solution
data NestedList a = Elem a | List [NestedList a]
flatten :: NestedList a -> [a]
flatten (Elem x) = [x]
flatten (List x) = concatMap flatten x
-- Tests
testcase1 = flatten (Elem 5)
assertion1 = [5]
testcase2 = flatten (List [Elem 1, List [Elem 2, List [Elem 3, Elem 4], Elem 5]])
assertion2 = [1,2,3,4,5]
-- This explodes
-- testcase3 = flatten (List [])
-- so does this:
-- testcase3' = flatten (List []) :: Eq a => [a]
-- this does not
testcase3'' = flatten (List []) :: Num a => [a]
-- type def based off `:t assertEqual`
assertEmptyList :: (Eq a, Show a) => String -> [a] -> Assertion
assertEmptyList str xs = assertEqual str xs []
test1 = TestCase $ assertEqual "" testcase1 assertion1
test2 = TestCase $ assertEqual "" testcase2 assertion2
test3 = TestCase $ assertEmptyList "" testcase3''
tests = TestList [test1, test2, test3]
-- Main
main = runTestTT tests
1st situation: testcase3 = flatten (List [])
GHCi, version 7.4.2: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Main ( problem7.hs, interpreted )
problem7.hs:29:20:
Ambiguous type variable `a0' in the constraints:
(Eq a0)
arising from a use of `assertEmptyList' at problem7.hs:29:20-34
(Show a0)
arising from a use of `assertEmptyList' at problem7.hs:29:20-34
Probable fix: add a type signature that fixes these type variable(s)
In the second argument of `($)', namely
`assertEmptyList "" testcase3'
In the expression: TestCase $ assertEmptyList "" testcase3
In an equation for `test3':
test3 = TestCase $ assertEmptyList "" testcase3
Failed, modules loaded: none.
Prelude>
2nd situation: testcase3 = flatten (List []) :: Eq a => [a]
GHCi, version 7.4.2: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Main ( problem7.hs, interpreted )
problem7.hs:22:13:
Ambiguous type variable `a0' in the constraints:
(Eq a0)
arising from an expression type signature at problem7.hs:22:13-44
(Show a0)
arising from a use of `assertEmptyList' at problem7.hs:29:20-34
Possible cause: the monomorphism restriction applied to the following:
testcase3 :: [a0] (bound at problem7.hs:22:1)
Probable fix: give these definition(s) an explicit type signature
or use -XNoMonomorphismRestriction
In the expression: flatten (List []) :: Eq a => [a]
In an equation for `testcase3':
testcase3 = flatten (List []) :: Eq a => [a]
Failed, modules loaded: none.
It's not so much the monomorphism restriction, it's the resolution of ambiguous type variables by defaulting that causes the compilation failure.
-- This explodes
-- testcase3 = flatten (List [])
-- so does this:
-- testcase3' = flatten (List []) :: Eq a => [a]
-- this does not
testcase3'' = flatten (List []) :: Num a => [a]
flatten :: NestedList a -> [a]
flatten (Elem x) = [x]
flatten (List x) = concatMap flatten x
flatten imposes no constraints on the type variable a, so there's no problem with the definition of testcase3 as such, it would be polymorphic.
But when you use it in test3,
test3 = TestCase $ assertEmptyList "" testcase3 -- ''
you inherit the constraints of
assertEmptyList :: (Eq a, Show a) => String -> [a] -> Assertion
Now the compiler has to find out at which type testcase3 should be used there. There is not enough context to determine the type, so the compiler tries to resolve the type variable by defaulting. According to the defaulting rules, a context (Eq a, Show a) cannot be resolved by defaulting, since only contexts involving at least one numeric class are eligible for defaulting. So compilation fails due to an ambiguous type variable.
testcase3' and testcase3'' however fall under the monomorphism restriction due to the expression type signature which imposes constraints on the right hand side of the definition that are inherited by the left.
testcase3' fails to compile due to that, regardless of whether it is used in an assertion.
testcase3'' gets defaulted to [Integer] since the expression type signature imposes a numeric constraint. Thus when the type is monomorphised for testcase'', the constrained type variable is defaulted to Integer. Then there is no question of the type at which it is used in test3.
If you had given type signatures to the bindings instead of to the right hand side,
testcase3' :: Eq a => [a]
testcase3' = flatten (List [])
testcase3'' :: Num a => [a]
testcase3'' = flatten (List [])
both values would have compiled on their own to polymorphic values, but still only testcase3'' would be usable in test3, since only that introduces the required numeric constraint to allow defaulting.