"Overloaded signature conflicts with monomorphism restriction"

Question

Why is this allowed:

i :: Num a => a
i = 1

While none of these is allowed:

i' :: Num a => a
Just i' = Just 1

x, y :: Num a => a
(x, y) = (1, 2)

x :: Num a => a
y :: Num a => a
(x, y) = (1, 2)

y :: Num a => a
x :: Num a => a
(x, y) = (1, 2)

m :: ()
n :: Num a => a
(n, m) = (1, ())

n :: Num a => a
m :: ()
(n, m) = (1, ())

Unless turned off monomorphism restriction by {-# LANGUAGE NoMonomorphismRestriction #-}, trying to compile with any of them always results in "Overloaded signature conflicts with monomorphism restriction".

But haven't I already specified all the types here? How could the monomorphism restriction even come up in the first place?

Answer 1

Quoth the rule:

We say that a given declaration group is unrestricted if and only if:
(a): every variable in the group is bound by a function binding or a simple pattern binding (Section 4.4.3.2), and
(b): an explicit type signature is given for every variable in the group that is bound by simple pattern binding.

What is a simple pattern binding though? There are two contradictory definitions.

(4.5.5 The Monomorphism Restriction) a simple pattern binding is a pattern binding in which the pattern consists of only a single variable

and

(4.4.3.2 Pattern bindings) A simple pattern binding has form p = e

According to the first definition, none of your failed bindings are simple, so they cannot be unrestricted, which means the mononorphism restriction applies to them. According to the second definition, all are simple and unrestricted, that is, the mononorphism restriction should not apply.

The applicable definition should be the first one as detailed in this posting and that's what the compiler is using, but AFAICT the report is not updated to reflect this.

Answer 2

The monomorphism restriction means that a simple pattern binding isn’t automatically given a polymorphic type when that type would include typeclass constraints, unless you include a type signature.

The Haskell Report (1998 and 2010) is a little inconsistent about the definitions of “simple” vs. “general” patterns. In §4.4.3.2 Pattern bindings it says “A simple pattern binding has form p = e” where p indicates a pattern, not just a variable; but §4.5.5 The Monomorphism Restriction it says “a simple pattern binding is a pattern binding in which the pattern consists of only a single variable” (emphasis mine) and refers to §4.4.3. This seems to be the intended meaning—so a simple binding has this form, without any guards, nor a where clause:

⟨variable⟩ = ⟨expression⟩

And a group of declarations is unrestricted just when each of its members is defined by either a simple binding with an explicit type signature, or a function binding of this form:

⟨variable⟩ ⟨pattern⟩+
 ( = ⟨expression⟩
 | ( | ⟨guard⟩ = ⟨expression⟩ )+ )
 ( where { ⟨declarations⟩ } )?

So, in your first example, desugared a little:

i :: forall a. Num a => a
i = fromInteger (1 :: Integer)

i is unrestricted because it’s a simple binding, and it has a type signature. The function fromInteger has type forall b. Num b => Integer -> b, and this instance of fromInteger has type Num c => Integer -> c for some type c. So the application fromInteger (1 :: Integer) has type Num c => c. c has no further constraints, and the restriction doesn’t apply, so the type gets generalised to forall d. Num d => d. And this matches the type signature i :: forall a. Num a => a, so everything checks out.

Whereas in your other examples, the variables i', x, y, m, and n are all defined by general patterns, not simple ones, and thus the restriction applies.

Haskell didn’t use to have TypeApplications (and relatedly, GHC Haskell lacked ScopedTypeVariables) so part of the motivation for the monomorphism restriction was to avoid ambiguous types (as in AllowAmbiguousTypes), which is explained in the Report with this example:

[The monomorphism restriction] prevents ambiguity. Consider the declaration group

[(n,s)] = reads t

Recall that reads is a standard function whose type is given by the signature

reads :: (Read a) => String -> [(a,String)]

Without [the restriction], n would be assigned the type forall a. Read a => a and s the type forall a. Read a => String. The latter is an invalid type, because it is inherently ambiguous. It is not possible to determine at what overloading to use s, nor can this be solved by adding a type signature for s. Hence, when non-simple pattern bindings are used (Section 4.4.3.2), the types inferred are always monomorphic in their constrained type variables, irrespective of whether a type signature is provided. In this case, both n and s are monomorphic in a.

The same constraint applies to pattern-bound functions. For example, in

(f,g) = ((+),(-))

both f and g are monomorphic regardless of any type signatures supplied for f or g.

None of your examples is ambiguous in this way, because the type parameter a does appear in the type, in a way that it could be filled in by by a type annotation or application.

The other motivation for the monomorphism restriction given in that section is that it “prevents computations from being unexpectedly repeated”, which I do care about, so my preference these days is to enable -Wmonomorphism-restriction (which is not implied by -Wall) so that I get told which bindings might want a type signature.