CODEWITHSUNDEEP
haskell
Codey McCodeface
Codey McCodeface

Reputation: 3028

Haskell function composition confusion

I'm trying to learn haskell and I've been going over chapter 6 and 7 of Learn you a Haskell. Why don't the following two function definitions give the same result? I thought (f . g) x = f (g (x))?

Def 1

let{ t :: Eq x => [x] -> Int; t xs = length( nub xs)}
t [1]
1

Def 2 

let t = length . nub 
t [1]

<interactive>:78:4:
    No instance for (Num ()) arising from the literal `1'
    Possible fix: add an instance declaration for (Num ())
    In the expression: 1
    In the first argument of `t', namely `[1]'
    In the expression: t [1]

Upvotes: 3

Views: 199

Answers (2)

Tikhon Jelvis
Tikhon Jelvis

Reputation: 68152

The problem is with your type signatures and the dreaded monomorphism restriction. You have a type signature in your first version but not in your second; ironically, it would have worked the other way around!

Try this:

λ>let t :: Eq x => [x] -> Int; t = length . nub
λ>t [1]
1

The monomorphism restriction forces things that don't look like functions to have a monomorphic type unless they have an explicit type signature. The type you want for t is polymorphic: note the type variable x. However, with the monomorphism restriction, x gets "defaulted" to (). Check this out:

λ>let t = length . nub
λ>:t t
t :: [()] -> Int

This is very different from the version with the type signature above!

The compiler chooses () for the monomorphic type because of defaulting. Defaulting is just the process Haskell uses to choose a type from a typeclass. All this really means is that, in the repl, Haskell will try using the () type if it encounters an ambiguous type variable in the Show, Eq or Ord classes. Yes, this is basically arbitrary, but it's pretty handy for playing around without having to write type signatures everywhere! Also, the defaulting rules are more conservative in files, so this is basically just something that happens in GHCi.

In fact, defaulting to () seems to mostly be a hack to make printf work correctly in GHCi! It's an obscure Haskell curio, but I'd ignore it in practice.

Apart from including a type signature, you could also just turn the monomorphism restriction off in the repl:

λ>:set -XNoMonomorphismRestriction

This is fine in GHCi, but I would not use it in real modules--instead, make sure to always include a type signature for top-level definitions inside files.

EDIT: Ever since GHC 7.8.1, the monomorphism restriction is turned off by default in GHCi. This means that all this code would work fine with a recent version of GHCi and you do not need to set the flag explicitly. It can still be an issue for values defined in a file with no type signature, however.

Upvotes: 9

shang
shang

Reputation: 24802

This is another instance of the "Dreaded" Monomorphism Restriction which leads GHCi to infer a monomorphic type for the composed function. You can disable it in GHCi with

> :set -XNoMonomorphismRestriction

Upvotes: 1

Related Questions