问题
While looking for Polyvariadic function examples, I found this resource: StackOverflow: How to create a polyvariadic haskell function?, and there was an answer snippet like this:
class SumRes r where
sumOf :: Integer -> r
instance SumRes Integer where
sumOf = id
instance (Integral a, SumRes r) => SumRes (a -> r) where
sumOf x = sumOf . (x +) . toInteger
Then we could use:
*Main> sumOf 1 :: Integer
1
*Main> sumOf 1 4 7 10 :: Integer
22
*Main> sumOf 1 4 7 10 0 0 :: Integer
22
*Main> sumOf 1 4 7 10 2 5 8 22 :: Integer
59
I tried out to change it a little bit, just for curiosity, because I found it pretty tricky at first glance, and I got into this:
class SumRes r where
sumOf :: Int -> r
instance SumRes Int where
sumOf = id
instance (SumRes r) => SumRes (Int -> r) where
sumOf x = sumOf . (x +)
I just changed Integer to Int and turned instance (Integral a, SumRes r) => SumRes (a -> r) where less polymorphic to instance (SumRes r) => SumRes (Int -> r) where
To compile it I had to set XFlexibleInstances flag. When I tryed to test sumOf function I got a problem:
*Main> sumOf 1 :: Int
1
*Main> sumOf 1 1 :: Int
<interactive>:9:9
No instance for (Num a0) arising from the literal `1'
The type variable `a0' is ambiguous...
Then I tried:
*Main> sumOf (1 :: Int) (1 :: Int) :: Int
2
Why can't Haskell infer that we want an Int in this situation, considering we are using Int within our SumRes typeclass?
回答1:
The instance
instance (...) => SumRes (Int -> r) where
roughly means "here's how to define SumRes on Int -> r for any r (under certain conditions)". Compare it with
instance (...) => SumRes (a -> r) where
which means "here's how to define SumRes on a -> r for any a,r (under certain conditions)".
The main difference is that the second one states that this is the relevant instance whichever the types a,r might be. Barring some (very tricky and potentially dangerous) Haskell extension, one can not add more instances later on involving functions. Instead, the first one leaves room for new instances such as e.g.
instance (...) => SumRes (Double -> r) where ...
instance (...) => SumRes (Integer -> r) where ...
instance (...) => SumRes (Float -> r) where ...
instance (...) => SumRes (String -> r) where ... -- nonsense, but allowed
This is paired with the fact that numeric literals such as 5 are polymorphic: their type must be inferred from the context. Since later on the compiler might find e.g. a Double -> r instance and choose Double as the literal types, the compiler does not commit to the Int -> r instance, and reports the ambiguity in a type error.
Note that, using some (safe) Haskell extensions (such as TypeFamilies), it is possible to "promise" to the compiler that your Int -> r is the only one that will be declared in the whole program. This is done like this:
instance (..., a ~ Int) => SumRes (a -> r) where ...
This promises to handle all the "functional type" cases, but requires that a is actually the same type as Int.
回答2:
Number literals are themselves polymorphic, rather than being of type Int
*Main> :t 1
1 :: Num a => a
Take a look what happens when we get the type signature:
*Main> :t sumOf 1 2 3
sumOf 1 2 3 :: (Num a, Num a1, SumRes (a -> a1 -> t)) => t
Notice that the type does not mention Int at all. The type checker can't figure out how to actually compute the sum because none of the defined Int instances are general enough to apply here.
If you fix the types to be Int, then you end up with
*Main> :t sumOf (1 :: Int) (2 :: Int) (3 :: Int)
sumOf (1 :: Int) (2 :: Int) (3 :: Int) :: SumRes t => t
*Main> :t sumOf (1 :: Int) (2 :: Int) (3 :: Int) :: Int
sumOf (1 :: Int) (2 :: Int) (3 :: Int) :: Int
Note that SumRes t => t is compatible with Int because we have a SumRes Int instance, but if we don't explicitly specify Int, then we have no instances general enough to apply here, because there is no general SumRes t instance.
来源：https://stackoverflow.com/questions/33333614/haskell-polyvariadic-function-and-type-inference