Polymorphic signature for non-polymorphic function: why not?

Question

As an example, consider the trivial function

f :: (Integral b) => a -> b
f x = 3 :: Int

GHC complains that it cannot deduce (b ~ Int). The definition matches the signature in the sense that it returns something that is Integral (namely an Int). Why would/should GHC force me to use a more specific type signature?

Thanks

This signature says that the function can return any Integral type, which is obviously not true. — n. 1.8e9-where's-my-share m.

hammar hammar · Accepted Answer · 2012-02-29T20:44:17

Type variables in Haskell are universally quantified, so Integral b => b doesn't just mean some Integral type, it means any Integral type. In other words, the caller gets to pick which concrete types should be used. Therefore, it is obviously a type error for the function to always return an Int when the type signature says I should be able to choose any Integral type, e.g. Integer or Word64.

There are extensions which allow you to use existentially quantified type variables, but they are more cumbersome to work with, since they require a wrapper type (in order to store the type class dictionary). Most of the time, it is best to avoid them. But if you did want to use existential types, it would look something like this:

{-# LANGUAGE ExistentialQuantification #-}

data SomeIntegral = forall a. Integral a => SomeIntegral a

f :: a -> SomeIntegral
f x = SomeIntegral (3 :: Int)

Code using this function would then have to be polymorphic enough to work with any Integral type. We also have to pattern match using case instead of let to keep GHC's brain from exploding.

> case f True of SomeIntegral x -> toInteger x
3
> :t toInteger
toInteger :: Integral a => a -> Integer

In the above example, you can think of x as having the type exists b. Integral b => b, i.e. some unknown Integral type.

Polymorphic signature for non-polymorphic function: why not?

3 Answers