Why is GHCi accepting something at the prompt that won't compile?

Question

I'm trying to play around with Haskell types, creating a data taking a type constructor and a concrete type (inspired by this).

Here is my kung.hs file:

data Kung t a = Kung { field :: t a } deriving (Show, Eq)

val1 = Kung { field = [1,5] }

val2 = Kung { field =  Just 3 }

--val3 = Kung { field =  3 }

It compiles fine and loads ok:

*Main> :load C:\Test\Haskell\kung.hs
[1 of 1] Compiling Main             ( C:\Test\Haskell\kung.hs, interpreted )
Ok, one module loaded.
*Main> val1
Kung {field = [1,5]}
*Main> val2
Kung {field = Just 3}
*Main>

Now the same version, but uncommenting val3:

data Kung t a = Kung { field :: t a } deriving (Show, Eq)

val1 = Kung { field = [1,5] }

val2 = Kung { field =  Just 3 }

val3 = Kung { field =  3 }

This does not compile :

*Main> :load C:\Test\Haskell\kung.hs
[1 of 1] Compiling Main             ( C:\Test\Haskell\kung.hs, interpreted )

C:\Test\Haskell\kung.hs:7:24: error:
    * No instance for (Num (t0 a0)) arising from the literal `3'
    * In the `field' field of a record
      In the expression: Kung {field = 3}
      In an equation for `val3': val3 = Kung {field = 3}
  |
7 | val3 = Kung { field =  3 }
  |                        ^
Failed, no modules loaded.

which seems fine. There is no way to "decompose" / "construct" (maybe not the right terminology used here) the value 3 of type Num from some type constructor and some concrete type.

Going back to the GHCi interpreter, load the first version of the file without the val3 commented and then:

Prelude> :load C:\Test\Haskell\kung.hs
[1 of 1] Compiling Main             ( C:\Test\Haskell\kung.hs, interpreted )
Ok, one module loaded.
*Main> val3 = Kung { field =  3 }
*Main> :t val3
val3 :: Num (t a) => Kung t a

How should I understand that? Why did GHCi artificially "manage" to decompose 3? (without giving a real type)

Then this val3 does not really seem viable:

*Main> val3

<interactive>:50:1: error:
    * Ambiguous type variables `t0', `a0' arising from a use of `print'
      prevents the constraint `(Show (t0 a0))' from being solved.
      Probable fix: use a type annotation to specify what `t0', `a0' should be.
      These potential instances exist:
        instance (Show b, Show a) => Show (Either a b)
          -- Defined in `Data.Either'
        instance [safe] Show (t a) => Show (Kung t a)
          -- Defined at C:\Test\Haskell\kung.hs:1:49
        instance Show a => Show (Maybe a) -- Defined in `GHC.Show'
        ...plus 15 others
        ...plus one instance involving out-of-scope types
        (use -fprint-potential-instances to see them all)
    * In a stmt of an interactive GHCi command: print it
*Main>

What is the subtlety happening here?

Answer 1

This is the Dreaded Monomorphism Restriction at work. The following compiles fine:

data Kung t a = Kung { field :: t a } deriving (Show, Eq)

val3 :: Num (t a) => Kung t a
val3 = Kung { field =  3 }

however, the monomorphism restriction prevents GHC from inferring this signature itself. Instead, it tries to find a monomorphic type. For this it only has the Haskell defaulting rules available. Normally, these imply that a Num-constrained type variable is monomorphised to Integer... but integer is not of the form t a, so this fails.

The correct fix is to, indeed, write the type signature yourself, but you can also turn off the monomorphism restriction:

{-# LANGUAGE NoMonomorphismRestriction #-}

data Kung t a = Kung { field :: t a } deriving (Show, Eq)

val3 = Kung { field =  3 }

In GHCi, the monomorphism restriction is turned off by default since, GHC-7.8 I believe it was. That's why the problem doesn't arise there.