On Tue, Apr 10, 2012 at 05:30:37PM -0400, Mike Meyer wrote:
On Tue, 10 Apr 2012 16:57:38 -0300 j.romildo@gmail.com wrote:
Hello.
Given the following function definitions
f 0 = True
g False = True
ghc infers the following types for the functions:
f :: (Eq a, Num a) => a -> Bool g :: Bool -> Bool
Why f has "Eq a" in the context in ts type, and g does not?
Bool is an instance of Eq, so there's no need to say that your (non-existent) type variable has that constraint.
Using a numeric constants means you get a type variable with the Num constraint. Since Num doesn't imply Eq, that constraint is (as Tim pointed out) required so the guard can be checked.
Then consider the following type and function definitions: data T = A | B h A = True h B = False The type T is not an instance of Eq. The inferred type by ghc for the function h is h :: T -> Bool which does not require T to be an instance of the Eq class. Therefore pattern matching on the constant data constuctors A and B is not related to the Eq class, which provides the equality function (==). This example contradicts the explanation given above by Mike. And the question remains: why pattern matching on numeric constants, differently from other constants, requires the Eq class? Romildo