However, this load into ghci (and compiles) just fine. When I executed maxFactor 1, it complains (of course):

<interactive>:0:1:
No instance for (Integral ([a0] -> a0))
arising from a use of `maxFactor'
Possible fix:
add an instance declaration for (Integral ([a0] -> a0))
In the expression: maxFactor 1
In an equation for `it': it = maxFactor 1
<interactive>:0:11:
No instance for (Num ([a0] -> a0))
arising from the literal `1'
Possible fix: add an instance declaration for (Num ([a0] -> a0))
In the first argument of `maxFactor', namely `1'
In the expression: maxFactor 1
In an equation for `it': it = maxFactor 1

However, I don't understand this behavior:

fac's type is:

fac :: Integral a => a -> [a]

while maxFactor's type is:

maxFactor :: Integral ([a] -> a) => ([a] -> a) -> [a] -> a

Doesn't this mean the following:

the first input to fac must be of typeclass Integral (e.g., fac 10);

since in the definition of maxFactor, there is fac x, x must also be of typeclass Integral, thus, maxFactor's type would be begin with something like maxFactor :: (Integral a) => a ->... then something else? However, if that is the case, then why this code compiles since the return of maxFactor can be x or head, which when following this line of reasoning, does not have the same type?

For what it's worth, if you compile with -Wall (or add that to your default ghci options, so that ghci "compiles" with -Wall) you'll get a warning because you didn't put a type signature on maxFactor. Then, presumably, you'll write maxFactor :: Integral a => a -> a and it will fail to compile.
–
MatrixFrogApr 11 '12 at 7:02

2 Answers
2

in maxFactor the compiler infers that the function argument x necessarily has the same type as head (in your if clause). Since you also call fac on x (which in turn calls mod) it infers that x is also some Integral class type. Consequently, the compiler infers the type

maxFactor :: Integral ([a] -> a) => ([a] -> a) -> [a] -> a

that takes some head-like and integer-like argument... which is unlikely to be a real thing.

I think the fact that you can load that code into GHCi is more a quirk of the interpreter. If you were just compiling the code above, it would fail.

Edit: I guess the issue is that the type checker can make sense of your code, however there probably isn't any sensible way to use it.

Actually it could compile (My version is 7.2.1) :( Is this a bug in GHC now? I wonder... But still, thanks!
–
Ziyao WeiApr 10 '12 at 15:55

@ZiyaoWei not if you try to add those inferred type declarations.
–
soulcheckApr 10 '12 at 15:57

4

@ZiyaoWei: It's not a bug. GHC can't know there will never be a function [a]->a that is an instance of Integral.
–
leftaroundaboutApr 10 '12 at 15:57

Looks fishy to me, too. Of course, you could never actually use it in your compiled program.
–
SarahApr 10 '12 at 15:57

4

@ZiyaoWei If you want a function to be of class Integral just do it: instance Integral ([a]->a) (you'll need FlexibleInstances to compile it). You'll also have to make it and instance of Num. Exactly what you want the methods to do, well, I'll leave that to you.
–
augustssApr 10 '12 at 16:14

As you've noticed correctly, the use of function fac inside of maxFactor adds a Integral a constraint on the type of x. So x needs to be of type Integral a => a.

In addition, the compiler sees that maxFactor either returns head, which has type [a]->a or x. Therefore x must have the more specific type Integral ([a]->a) => ([a]->a), and so maxFactor has type

maxFactor :: Integral ([a] -> a) => ([a] -> a) -> ([a] -> a)

which is exactly what you got. There's nothing "wrong" with this definition so far. If you managed to write an instance of Integral type ([a]->a) you could invoke maxFactor without problem. (Obviously maxFactor wouldn't work as expected.)