Why the compiler does not commit to a type class?

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

Why the compiler does not commit to a type class?

Alexander Chen
hi,

Prelude> u = undefined
Prelude> k :: (Ord a, Num b) => a -> b -> a; k = u

Prelude> :t k 1 2 
k 1 2 :: (Ord a, Num a) => a

Prelude> :t k (1 :: Integer) 2
k (1 :: Integer) 2 :: Integer

In the first version the compiler is not really pushed so it simply gives back the type class constriction it has to adhere to. While in the second it is pushed to give an more specific answer and thus the :: Integer.

Question:
Is this train of thought correct? 




_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Re: Why the compiler does not commit to a type class?

Jason Chau
Yes - if you look at the number types, you will find different number types and not integer types are providing support that’s not in Integer, so compiler is giving safest assumption.

Sent from my iPhone

On Apr 17, 2020, at 12:56 PM, Alexander Chen <[hidden email]> wrote:


hi,

Prelude> u = undefined
Prelude> k :: (Ord a, Num b) => a -> b -> a; k = u

Prelude> :t k 1 2 
k 1 2 :: (Ord a, Num a) => a

Prelude> :t k (1 :: Integer) 2
k (1 :: Integer) 2 :: Integer

In the first version the compiler is not really pushed so it simply gives back the type class constriction it has to adhere to. While in the second it is pushed to give an more specific answer and thus the :: Integer.

Question:
Is this train of thought correct? 



_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners

_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners