Home/ Questions/Q 930337
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T20:19:03+00:00

If I write foo :: (Num a) => a foo = 42 GHC happily

  • 0

If I write

foo :: (Num a) => a
foo = 42

GHC happily accepts it, but if I write

bar :: (Num a) => a
bar = (42 :: Int)

it tells me that the expected type a doesn’t match the inferred type Int. I don’t quite understand why, since Int is an instance of the class Num that a stands for.

I’m running into this same situation while trying to write a function that, boiled down to the core of the problem, looks roughly like this:

-- Note, Frob is an instance of class Frobbable
getFrobbable :: (Frobbable a) => Frob -> a
getFrobbable x = x

Is it possible to write a function like this? How can I make the result compatible with the type signature?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    You are treating typeclass constraints as if they were subtype constraints. This is a common thing to do, but in fact they only coincide in the contravariant case, that is, when concerning function arguments rather than results. The signature:

    bar :: (Num a) => a

    Means that the caller gets to choose the type a, provided that it is an instance of Num. So here, the caller may choose to call bar :: Int or bar :: Double, they should all work. So bar :: (Num a) => a must be able to construct any kind of number, bar does not know what specific type was chosen.

    The contravariant case is exactly the same, it just corresponds with OO programmers’ intuition in this case. Eg.

    baz :: (Num a) => a -> Bool

    Means that the caller gets to choose the type a, again, and again baz does not know what specific type was chosen.

    If you need to have the callee choose the result type, just change the signature of the function to reflect this knowledge. Eg.:

    bar :: Int

    Or in your getFrobbable case, getFrobbable :: Frob -> Frob (which makes the function trivial). Anywhere that a (Frobbable a) constraint occurs, a Frob will satisfy it, so just say Frob instead.

    This may seem awkward, but it’s really just that information hiding happens at different boundaries in functional programming. There is a way to hide the specific choice, but it is uncommon, and I consider it a mistake in most cases where it is used.

    • 0