Tobias Dammers

programming

Object-Oriented Haskell

Part 3: Generalized Mutability

Nov 21, 2017

In Part 1, we have seen how an interface-based OOP model can be implemented in idiomatic Haskell, and we then extended this model to allow for mutable objects by using IORef in Part 2. In this part, we will extend the model further to decouple the mutable-variable implementation from mutability in the objects themselves.

Generalizing Mutable Variables

Let’s look at the bare minimum interface for mutable variables. We need the following building blocks:

We can implement these primitives for IORef like this:

Let’s look at another mutable-variable type: TVar.

Obviously the m type for TVar is STM.

Mutability Typeclasses

The above means that we will want the three functions there to be polymorphic over m and v. The idiomatic way of achieving that in Haskell is to use a typeclass; since two types are involved here, we are going to need the MultiParamTypeClasses extension here. So:

This works, but we will take a slightly different approach: instead of one typeclass, we will introduce two of them:

In practice, we will address two additional concerns: 1. The v type is not generally going to be mentioned in our method signatures, which means that we need to somehow tell the compiler how to infer v from a given m. 2. Whenever we are going to write to a variable, this will generally also involve reading from variables, either the same one or another.

Issue 2 is easy to address: we will simply use subclassing to make sure that WriteVar always implies ReadVar. So:

GHC has two extensions that can both solve the second problem: FunctionalDependencies (a.k.a. fundeps), and TypeFamilies. Using fundeps, this is what the typeclasses end up looking like:

For those unfamiliar with fundeps, the m -> v part means “the choice of v depends on the choice of m”, or, put differently, “the choice of m determines the choice of v”. Meaning that once we have written one instance for any combination of m and v, we are not allowed to write another instance that involves the same m.

With this functional dependency in place, we can specify just the m and have the compiler infer the correct v from it.

And now we’ll write instances:

Mutable Objects Generalized

Armed with the above, let’s generalize our mutable objects and interfaces, starting with the Renderable interface:

The Label type also needs to be generalized:

Conclusion

We have achieved two important goals here.

First, neither the Label type, nor the Render interface, nor the Render implementation for Label, mention IO or IORef anywhere, they are completely expressed in terms of the abstract ReadVar and WriteVar typeclasses. We have decoupled mutability semantics from mutability implementation. And this means that we can now use them in an STM context without further ado - at least if we also generalize our drawing primitives:

Second, by splitting up the mutability typeclass into “read-only access” and “read-write access” typeclasses, we can declare some methods as “read-only”, and as long as our ReadVar instances are lawful, it will be impossible to implement them such that they mutate anything. At the same time, if we want to call such a read-only method from a read-write context, we can, because every read-write context is also a read-only context (because ReadVar v m => WriteVar v m), very much similar to how const works in C++.

By the way, the OOP framework laid out in this blog series is also available on Hackage, under the name boop, feel free to read along and see what it looks like when you put it all together.