Is the dispatch of a Haskell TypeClass dynamic?

Question

Given the following Haskell code snapshot:

class Foo a where
   bar  :: a -> ...
   quux :: a -> ...
   ...

Where the value of a is determined at runtime - the class dispatches on this value.

I'm assuming that the compiler can statically check the types at compile-time, and ensure that no invalid types can dispatch on it.

Now if we compare this to a dynamic dispatch in Java:

interface Flippable {
  Flippable flip();
}

class Left implements Flippable {
  Right flip();
}

class Right implements Flippable {
  Left flip();
}

class Demo {
  public static void main(String args[]) {
    Flippable flippable = new Right();
    System.out.println(flippable.flip);
  }
}

Assumptions:

• Haskell can dispatch on return type as well as multiple arguments making dispatch different to other languages.

My question is: Is the dispatch of a Haskell TypeClass dynamic?

Answer 1

It depends what you mean by "dynamic" dispatch. There aren't subtyping in haskell, so your Java example is hard to translate.

In situation when you have type class, say Show and want to put different elements into the list, you can use existential quantification:

{-# LANGUAGE ExistentialQuantification #-}

data Showable = forall a. Show a => Showable a

instance Show Showable where
  show (Showable x) = show x

test :: main ()
test = let list = [Showable True, Showable "string"]
       in print list

-- >>> test
-- [True,"string"]

Here you can say that dispatch happens "dynamically". It happens in the same way as in C++ or Java. The Show dictionary is carried with an object, like a vtable in C++ (or class definition ptr in Java, dunno how it's called).

Yet, as @MathematicalOrchid explained, this is an anti-pattern.

---

Yet if you want to flip from Left to Right and back, you can state that in type class definition.

{-# LANGUAGE ExistentialQuantification #-}
{-# LANGUAGE FunctionalDependencies #-}

class Flippable a b | a -> b where
  flip' :: Flippable b a => a -> b

newtype INL = INL Int deriving Show
newtype INR = INR Int deriving Show

instance Flippable INL INR where
  flip' (INL x) = INR x

instance Flippable INR INL where
  flip' (INR x) = INL x

-- >>> flip' $ INL 1
-- INR 1
-- >>> flip' $ flip' $ INL 1
-- INL 1

In this case flip' calls are resolved already at compile-time.

---

You could have have class Flip a where flip' :: a -> Flippable using existential quantification too. Then consecutive calls will be dispatched dynamically. As always, it depends on your needs.

{-# LANGUAGE ExistentialQuantification #-}
{-# LANGUAGE FunctionalDependencies #-}
{-# LANGUAGE StandaloneDeriving #-}

class Flip a where
  flip' :: a -> Flippable

-- Show is only for repl purposes
data Flippable = forall a. (Flip a, Show a) => Flippable a

deriving instance Show Flippable

instance Flip Flippable where
  flip' (Flippable x) = flip' x

newtype INL = INL Int deriving Show
newtype INR = INR Int deriving Show

instance Flip INL where
  flip' (INL x) = Flippable (INR x)

instance Flip INR where
  flip' (INR x) = Flippable (INL x)

-- >>> flip' $ flip' $ flip' $ INL 1
-- Flippable (INR 1)

---

Hopefully this answers your question.

Answer 2

If your code is Haskell 2010, with no language extensions turned on, Haskell actually doesn't support run-time polymorphism at all!

That's quite surprising. Haskell feels like a very polymorphic language. But in fact, all the types can in principle be decided purely at compile-time. (GHC chooses not to, but that's an implementation detail.)

This is exactly the same situation as C++ templates. When you write something like std::vector<int>, the compiler knows, at compile-time, all the times involved. The really surprising thing is just how rarely you actually need true run-time polymorphism!

Now, there are scenarios where you want to run different code based on run-time circumstances. But in Haskell, you can do that just by passing a function as an argument; you don't need to create a "class" (in the OOP sense) merely to achieve this.

Now, if you turn on some language extensions (most conspicuously ExistentialQuantification) then you get true, run-time polymorphism.

Note that the main reason people seem to do this is so you can do

class Foo f where
  bar :: f -> Int
  baz :: f -> Bool

data AnyFoo = forall f. Foo => AnyFoo f

my_list :: [AnyFoo]
...

This is widely considered a Haskell anti-pattern. In particular, if you upcast stuff in Java to put it into a list, you then later downcast it again. But the code above offers no possibility to ever downcast. You also can't use run-time reflection (since Haskell doesn't have that either). So really, if you have a list of AnyFoo, the only thing you can do with it is call foo or bar on it. So... why not just store the result of foo and bar?

data AnyFoo = AnyFoo {foo :: Int, bar :: Bool}

It lets you do exactly the same stuff, but doesn't require any non-standard extensions. In fact, in some ways, it's actually a bit more flexible. You now don't even need a Foo class, you don't need to define a new type for every sort of Foo you might have, just a function that constructs the AnyFoo data structure for it.