Why can a Num act like a Fractional?

chi’s answer gives a great high-level explanation of what’s happening. I thought it might also be fun to give a slightly more low-level (but also more mechanical) way to understand this, so that you might be able to approach other similar problems, turn a crank, and get the right answer. I’m going to talk about types as a sort of protocol between the user of the value of that type and the implementer.

• For forall a. t, the caller gets to choose a type, then they continue with protocol t (where a has been replaced with the caller’s choice everywhere in t).
• For Foo a => t, the caller must provide proof to the implementer that a is an instance of Foo. Then they continue with protocol t.
• For t1 -> t2, the caller gets to choose a value of type t1 (e.g. by running protocol t1 with the roles of implementer and caller switched). Then they continue with protocol t2.
• For any type t (that is, at any time), the implementer can cut the protocol short by just producing a value of the appropriate type. If none of the rules above apply (e.g. if we have reached a base type like Int or a bare type variable like a), the implementer must do so.

Now let’s give some distinct names to your terms so we can differentiate them:

valFrac :: forall a. Fractional a =>      a
valNum  :: forall a. Num        a =>      a
idFrac  :: forall a. Fractional a => a -> a
idNum   :: forall a. Num        a => a -> a

We also have two definitions we want to explore:

applyIdNum :: forall a. Fractional a => a
applyIdNum = idNum valFrac

applyIdFrac :: forall a. Fractional a => a
applyIdFrac = idFrac valNum

Let’s talk about applyIdNum first. The protocol says:

1. Caller chooses a type a.
2. Caller proves it is Fractional.
3. Implementer provides a value of type a.

The implementation says:

1. Implementer starts the idNum protocol as the caller. So, she must:

   1. Choose a type a. She quietly makes the same choice as her caller did.
   2. Prove that a is an instance of Num. This is no problem, because she actually knows that a is Fractional, and this implies Num.
   3. Provide a value of type a. Here she chooses valFrac. To be complete, she must then show that valFrac has the type a.

2. So the implementer now runs the valFrac protocol. She:

   1. Chooses a type a. Here she quietly chooses the type that idNum is expecting, which happens to coincidentally be the same as the type that her caller chose for a.
   2. Prove that a is an instance of Fractional. She uses the same proof her caller did.
   3. The implementer of valFrac then promises to provide a value of type a, as needed.

For completeness, here is the analogous discussion for applyIdFrac. The protocol says:

1. Caller chooses a type a.
2. Caller proves that a is Fractional.
3. Implementer must provide a value of type a.

The implementation says:

1. Implementer will execute the idFrac protocol. So, she must:

   1. Choose a type. Here she quietly chooses whatever her caller chose.
   2. Prove that a is Fractional. She passes on her caller’s proof of this.
   3. Choose a value of type a. She will execute the valNum protocol to do this; and we must check that this produces a value of type a.

2. During the execution of the valNum protocol, she:

   1. Chooses a type. Here she chooses the type that idFrac expects, namely a; this also happens to be the type her caller chose.
   2. Prove that Num a holds. This she can do, because her caller supplied a proof that Fractional a, and you can extract a proof of Num a from a proof of Fractional a.
   3. The implementer of valNum then provides a value of type a, as needed.

With all the details on the field, we can now try to zoom out and see the big picture. Both applyIdNum and applyIdFrac have the same type, namely forall a. Fractional a => a. So the implementer in both cases gets to assume that a is an instance of Fractional. But since all Fractional instances are Num instances, this means the implementer gets to assume both Fractional and Num apply. This makes it easy to use functions or values that assume either constraint in the implementation.

P.S. I repeatedly used the adverb “quietly” for choices of types needed during the forall a. t protocol. This is because Haskell tries very hard to hide these choices from the user. But you can make them explicit if you like with the TypeApplications extension; choosing type t in protocol f uses the syntax f @t. Instance proofs are still silently managed on your behalf, though.