Why is type "Integer -> Integer" and not "(Num a) => a -> a"?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Why is type "Integer -> Integer" and not "(Num a) => a -> a"?

Nathan M. Holden
This is just a theory, but in my (limited) experience, GHCi is willing to
guess at the type of values, where at functions (explicitly or implicitly
typed) it can't guess.

In your original function, it multiplied a number (Num a) => a by an Int,
therefor it must be Int -> Int (because you can't multiply a Double by an Int,
don't be crazy.

In the new function, though, it can infer the type of the 2, and therefor it
can infer it to whatever numerical type you send it.

I've run into this problem a few times, but for whatever reason I can't get
myself to fall into any of the usual ways I walk blindly into these sorts of
problems this time.
Reply | Threaded
Open this post in threaded view
|

Why is type "Integer -> Integer" and not "(Num a) => a -> a"?

Chaddaï Fouché
On Thu, Nov 12, 2009 at 5:40 PM, Nathan M. Holden
<[hidden email]> wrote:
> This is just a theory, but in my (limited) experience, GHCi is willing to
> guess at the type of values, where at functions (explicitly or implicitly
> typed) it can't guess.
>
> In your original function, it multiplied a number (Num a) => a by an Int,
> therefor it must be Int -> Int (because you can't multiply a Double by an Int,
> don't be crazy.

That is not the problem : as the rest of your message acknowledge 2 is
not an Int, it is of type (Num a) => a. The issue rest squarely with
the fact that the binding f1 don't have parameter expressed on the
left side of the "=", thus the monomorphism restriction kicks in (as
alluded, probably, by your first paragraph) and GHC has to use the
defaulting rules to find a monomorphic type for f1.

--
Jeda?