3

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?

Community
  • 1
  • 1
FtheBuilder
  • 1,410
  • 12
  • 19
  • Looks like defaulting (assuming `1` means the `Int` 1) kicks in after instance resolution in `ghci`. Rightly so. You could add a separate bunch of step-case instances for `Integer` instead of `Int`, and then you'd have a real ambiguity. – pigworker Oct 25 '15 at 19:10
  • You may like to read [this question, and my answer to it](http://stackoverflow.com/q/10777283/791604) for some explanations in another direction, and a useful trick that you can use to deal with the bad type inference here: use `instance a ~ Int => SumRes (a -> r)` instead of `instance SumRes (Int -> r)`. – Daniel Wagner Oct 25 '15 at 19:18
  • To clarify the part about defaulting, `Int` is not a type that's normally defaulted to, but `Integer` is. Therefore the original code works by defaulting all the literals to `Integer`. – Ørjan Johansen Oct 26 '15 at 01:59
  • My comment turns out to be a bit naive, as even putting `Integer` instead of `Int` in the changed code isn't enough to fix it. (I was made aware of this by a just posted [duplicate question](http://stackoverflow.com/questions/33339017/why-does-the-number-literal-2-cannot-match-the-type-integer-in-the-following-cod).) – Ørjan Johansen Oct 26 '15 at 06:32

2 Answers2

5

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.

chi
  • 111,837
  • 3
  • 133
  • 218
  • 1
    This was exactly the point. When you said **here's how to define `SumRes` on `Int -> r` for any r (under certain conditions)**, it means that although we are explaining to the compiler in this specific case, it may be other ways like `Double -> r`. Another question: why isn't `TypeFamilies` default? Are there good reasons? – FtheBuilder Oct 25 '15 at 23:21
  • 2
    @FtheBuilder With a few notable exceptions, GHC attempts to follow [the Report](https://www.haskell.org/onlinereport/haskell2010/) by default, and type families are not in the Report. GHC is probably the only implementation that supports them; and since supporting them might be seen as a significant implementation burden, I suspect they will not become part of the Report in the near future. However, I would not consider `TypeFamilies` a controversial or "icky" extension; if you like it, and plan to use GHC, use it with impunity. – Daniel Wagner Oct 26 '15 at 01:11
3

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.

Simon Broadhead
  • 3,483
  • 21
  • 19