runST :: (forall s. ST s a) -> a 

runST enables Haskell to use local mutation without leaking any of the side effects to the outside. The higher-rank function parameter ensures that this is safe, and references cannot be accessed outside the call to runST.

…

You know what. It’s nearly 2026. Why am I explaining this when you could ask an LLM.¹ (This is ChatGPT. I’ll spare you the rambling)

bad :: STRef s Int
bad = runST (newSTRef 0)

Okay, that bad snippet does indeed not compile! So clearly this must be how ST works (and LLMs are always correct anyway obviously).

Let’s play with this a little and, let’s say, write a safe wrapper for alloca.

alloca is unsafe because leaking the Ptr and accessing it after the end of the continuation leads to use-after-free.

If we add a type parameter to our pointer type and universally quantify over it in allocaSafe, then ChatGPT told us that the pointer cannot escape its continuation. So as long as we make sure there is no way to get the underlying pointer back out, this should be safe!²

-- abstract
newtype SafePtr s a = MkSafePtr (Ptr a)
type role SafePtr nominal representational -- would you have thought of this? ^^

peekSafe :: Storable a => SafePtr s a -> IO a
peekSafe (MkSafePtr pointer) = peek pointer

pokeSafe :: Storable a => SafePtr s a -> a -> IO ()
pokeSafe (MkSafePtr pointer) x = poke pointer x

allocaSafe :: Storable a => (forall s. SafePtr s a -> IO b) -> IO b
allocaSafe f = do
   pointer <- malloc
   result <- f (MkSafePtr pointer)
   free pointer
   pure result

If we try this, we can see that the following code is rightfully rejected

allocaSafe @Int \safePtr -> pure safePtr

allocasafe.hs:24:48: error: [GHC-46956]
    • Couldn't match expected type ‘a0’
                  with actual type ‘SafePtr s Int’
        because type variable ‘s’ would escape its scope

So we’re safe, right?

There exists a problem

A seemingly quite unrelated feature of Haskell and many other languages is called existential types. Whereas a universally quantified type of the form forall a. ... can be instantiated to use any possible type for a, an existential type of the form exists a. ... uses one specific type a but doesn’t expose what it is (it only exposes that one such type “exists”).

Haskell — like most other languages — doesn’t directly expose an existential quantifier, but it still allows existentials in GADTs. For example, this defines a type SomeList that contains a list but doesn’t tell us what the type of its elements is.

data SomeList where
   MkSomeList :: [a] -> SomeList

So, if we wrap SafePtr in an existential, we can hide the s parameter we obtained from allocaSafe!

data NotSoSafePtr a where
   MkNotSoSafePtr :: SafePtr s a -> NotSoSafePtr a

Does this mean we can…

Use-after-free

main :: IO ()
main = do
    MkNotSoSafePtr pointer <- allocaSafe @Int \safePtr -> pure (MkNotSoSafePtr safePtr)
    pokeSafe pointer 42

$ valgrind safeptr
==230152== Memcheck, a memory error detector
[...]
==230569== Invalid write of size 8
==230569==    at 0x409C10: ghczminternal_GHCziInternalziForeignziStorable_zdfStorableInt1_info (in /home/prophet/temp/safeptr/safeptr)
==230569==  Address 0x4e69200 is 0 bytes inside a block of size 8 free'd
==230569==    at 0x484C8EF: free (vg_replace_malloc.c:989)
==230569==    by 0x409811: ghczminternal_GHCziInternalziForeignziMarshalziAlloc_free1_info (in /home/prophet/temp/safeptr/safeptr)
==230569==  Block was alloc'd at
==230569==    at 0x48497A8: malloc (vg_replace_malloc.c:446)
==230569==    by 0x40974E: ghczminternal_GHCziInternalziForeignziMarshalziAlloc_malloc_info (in /home/prophet/temp/safeptr/safeptr)

So how does ST actually work?

The guarantee ST gives is that an STRef (or similar) can only be read from or written to in the same runST invocation that created it.

The higher-rank continuation doesn’t directly contribute to this safety guarantee at all. It only creates a fresh type-level tag that uniquely identifies the runST invocation and links the STRef to it.

Leaking the STRef (or any other resource tagged this way) is absolutely possible. It just cannot be accessed after the leakage because any other runST call will use an ST monad with a different s variable.

Bonus: We don’t even need existentials

Using regular higher-rank types, we can encode an existential type like exists s. T s as a rank-2 function forall r. (forall s. T s -> r) -> r.

And that’s still enough for a use-after-free!³

newtype NotSoSafePtr a = MkNotSoSafePtr (forall r. (forall (s :: Type). SafePtr s a -> r) -> r)

main :: IO ()
main = do
    MkNotSoSafePtr usePtr <- allocaSafe @Int \safePtr -> pure (MkNotSoSafePtr \f -> f safePtr)
    usePtr \pointer -> pokeSafe pointer 42    

A common issue in impure ML-style languages with polymorphism and mutable references is the possibility of polymorphic references.

In a hypothetical impure language that had both these features, but no mitigations against polymorphic references, the following code would be extremely unsafe.

unsafeCoerce :: a -> b
unsafeCoerce x = 
    let dangerous = ref Nothing
    dangerous := Just x
    case dangerous of
        Nothing -> error "unreachable"
        Just y -> y

This code creates a reference dangerous with an initial value of Nothing, writes x to it, and then reads from it again. But because this language doesn’t prevent polymorphic references and Nothing has type forall a. Maybe a, dangerous is actually generalized to forall a. Ref (Maybe a). This means that in the line that writes to it, dangerous is instantiated to Maybe a, whereas in the line that reads from it, it is instantiated to Maybe b, although the value stored in it still has type a, breaking type safety and consequently memory safety!

Scary, right?

You might think that you could prevent this by just preventing generalization of reference types, but references can be hidden behind closures, so languages need a slightly blunter hammer: the value restriction.

The value restriction says that a let binding can only ever be given a polymorphic type if its bound expression is syntactically a “value”, i.e. an expression that obviously will not perform any computation. 5 is a value. So is Nothing. But sqrt 42 and (crucially) ref Nothing are not values and will not be generalized.¹

Haskell’s let bindings do not have a value restriction.

So, does this mean that Haskell’s type system is deeply unsound and we just never noticed?

No! If we translate the original example to Haskell, we will hit a type error, telling us that dangerous was not generalized.

unsafeCoerce :: a -> b
unsafeCoerce x = do
    dangerous <- newIORef Nothing
    writeIORef dangerous (Just x)
    result <- readIORef dangerous
    case result of
        Nothing -> error "unreachable"
        Just y -> y

MonadGen.hs:82:19: error: [GHC-25897]
    • Couldn't match type ‘a’ with ‘b’
      Expected: IO b
        Actual: IO a

But the interesting question here is: Why was it not generalized? To answer that, we will have to take a small step back.

What even is an IO

The important detail in this Haskell code is that dangerous was not bound in a let binding. It was bound in a monadic do-binding.

IO is famously a monad, so a do-binding like this is just syntactic sugar for an application of (>>=), which (specialized to IO) has the following type.

(>>=) :: forall a b. IO a -> (a -> IO b) -> IO b

So the value passed to the continuation (corresponding to the variable in the let binding) has whatever type is wrapped inside the IO type constructor of its first argument.

Now, newIORef Nothing can itself have a polymorphic type.

newIORef Nothing :: forall a. IO (IORef (Maybe a))

However, notice that the polymorphic forall quantifier occurs outside the IO! This means that the value passed to the continuation of (newIORef Nothing >>=) will always have type IORef _ and therefore be monomorphic. We can instantiate the a with forall a. Maybe a, but that only gives us a perfectly safe IORef (forall a. Maybe a)², not a forall a. IORef (Maybe a).

That’s the magic! The placement of the IO in the types prevents giving dangerous a polymorphic type.

What I really want you to appreciate here is just how similar this is to the traditional value restriction. If we’re allowed to do arbitrary effects, we might create a polymorphic reference, so ML bans all let bindings that look like they might perform effects, whereas Haskell already has a distinction between pure and effectful let bindings (>>=) and just needs to prevent the second group from being generalized.

Generalizable Monads

This hopefully all seems reasonable so far. IO can create mutable references so we need to prevent it from generalizing them and that’s why the monadic interface imposes something resembling the value restriction.

But… IO is not the only monad. If we look at Identity, it’s a monad that quite literally does nothing, so a do-binding in Identity is just a pure let-binding. Shouldn’t we at least be able to generalize do-bindings in a trivial monad like this?

Let’s think through what that would mean. Above, we couldn’t generalize newIORef Nothing because it had type forall a. IO (IORef (Maybe a)) with the forall on the outside. If it had type IO (forall a. IORef (Maybe a)), we could instantiate the a parameter to (>>=) with forall a. IORef (Maybe a) and therefore generalize it.

Coming back to Identity, we can generalize Identity bindings, if for any context f (e.g. f ~ IORef), we can turn something of type forall a. Identity (f a) into something of type Identity (forall a. f a). More generally, we can define a type class for monads where we can generalize bindings this way.

class (Monad m) => MonadGen m where
    generalize :: forall f. (forall a. m (f a)) -> m (forall a. f a)

So, can we define this for Identity? Yes!³

instance MonadGen Identity where
    generalize m = do
        let (Identity x) = m
        Identity x

If we use this new fancy function, our monadic bindings in Identity can be just as powerful as regular let bindings! (though a little less convenient since we need newtypes)

newtype Endo a = Endo (a -> a)

applyEndo :: Endo a -> a -> a
applyEndo (Endo f) x = f x

blah :: Identity (Bool, Char)
blah = do
    -- f :: forall a. Endo a <- pure (Endo (\x -> x))  -- fails
    f :: forall a. Endo a <- generalize (pure (Endo (\x -> x))) -- succeeds
    pure (applyEndo f True, applyEndo f 'a')

Nice! Since we made this a type class, you’re probably already wondering which other monads we can implement it for. Turns out, there are actually quite a few! For reasons that will become apparent in a moment, let’s look at…

State⁴

The State monad in Haskell is defined as⁵

newtype State s a = State (s -> (s, a))

In order to simulate mutable state, this definition represents computations as functions that take the current state as a parameter and return a new state value. As it turns out, if we just keep plumbing those state values around, nothing stops us from binding the result of this function in a let binding and thereby generalizing the result of the computation!

instance MonadGen (State s) where
    generalize m = do
        let (State f) = m
        State \s -> do
            let (s', result) = f s
            (s', result)

Great! So it seems like many pure monads do support binding generalization. Then there must be something about the internal structure of IO that is somehow special and prevents us from implementing MonadGen IO, right?

Right?

What is an IO, really?

A popular metaphor for impure functions in pure languages is that instead of modifying the world around it, a function like putStrLn essentially takes the real world as a parameter and returns a modified version of it where a string has been written to stdout. Interestingly enough, this is very close to how IO works internally!

newtype IO a = IO (State# RealWorld -> (# State# RealWorld, a #))

Of course, we cannot literally modify the real world as a pure value, so internally, putStrLn is an actual, impure function.

But the State# values still act both as capabilities (ensuring that impure functions can only be called from impure functions) and data dependencies (to ensure that impure functions are evaluated in the correct order despite laziness).

Using this constructor directly can be unsafe, since the illusion of purely modifying the real world (and IO’s sequencing guarantees) only apply if the State# RealWorld tokens are passed around linearly, i.e. are never duplicated or dropped. However, if we manually make sure to uphold this invariant and we don’t use any further GHC internals, common knowledge suggests that we should be safe.

That type definition looks familiar

It uses an unboxed tuple instead of a boxed one and is specialized to (zero-sized) unboxed State# RealWorld tokens, but otherwise IO is really just a state monad! So, if we were able to implement MonadGen for State, shouldn’t we be able to implement it for IO as well?

If we tried to copy the State definition directly, we would hit a quite awkwardly phrased error message⁶

instance MonadGen IO where
    generalize m = do
        let (IO f) = m
        IO \s -> do
            let (# s', result #) = f s
            (# s', result #)

MonadGen.hs:51:17: error: [GHC-20036]
    You can't mix polymorphic and unlifted bindings:
      (# s', result #) = f s
    Suggested fix: Add a type signature.

Unfortunately, the suggested fix doesn’t help us. Giving result a polymorphic type is the whole point here!

Fortunately, we can just box the State# RealWorld token first and avoid the issue.

data BoxedState s = BoxedState {state :: State# s}

liftState :: (# State# s, b #) -> (BoxedState s, b)
liftState (# s, b #) = (BoxedState s, b)

instance MonadGen IO where
    generalize m = do
        let (IO f) = m
        IO \s -> do
            let (boxedState, result) = liftState (f s)
            let (BoxedState{state}) = boxedState
            (# state, result #)

And this compiles! So, does that mean…

Yes!

newtype MaybeRef a = MaybeRef (IORef (Maybe a))

unsafeCoerceIO :: forall a b. a -> IO b
unsafeCoerceIO x = do
    maybeRef <- generalize (MaybeRef <$> newIORef Nothing)
    let MaybeRef ref = maybeRef
    writeIORef ref (Just x)
    readIORef ref >>= \case
        Just y -> pure y
        Nothing -> error "unreachable"

λ> unsafeCoerceIO @_ @String id
"fish: Job 1, 'ghci MonadGen.hs' terminated by signal SIGSEGV (Address boundary error)

Conclusion

What I want you to take away from this is that

• Despite its purity, Haskell does need something resembling the value restriction, just like every other ML with references.
• However, this value restriction is only given by the monadic interface of IO and not inherent to its definition.
• Contrary to popular belief, unwrapping the IO constructor is deeply unsafe and can violate memory safety, even if State# tokens are never duplicated or dropped.

module Unix : sig
    type file_descr (* abstract *)
    val open_file : string -> file_descr
    val read_file : file_descr -> string
end = struct
    type file_descr = int
    
    let open_file file = some_internal_c_code_that_returns_an_int file
    
    let read_file file_descr = some_internal_c_code_that_takes_an_int file_descr
end

From the perspective of writing modules like this, this feature is great! It means that the code inside the module can treat the type exactly as its underlying type and make whatever assumptions it needs to make without any additional ceremony because, inside the module, they are exactly equal!
But from the outside, you get a fully abstract type that users can make no assumptions about other than what you expose to them via the module signature.

Newtypes

Since Haskell’s module system is significantly less powerful than OCaml’s, it cannot implement abstract types in the same way. Instead, abstract types are implemented as data types or newtypes that don’t export their constructor.

While this achieves roughly the same effect, it means that any code inside the module that uses the underlying type needs to wrap and unwrap the newtype constructors everywhere.

module Unix
  ( FileDescr -- does not export its constructor (MkFileDescr)
  , openFile
  , readFile
  )

newtype FileDescr = MkFileDescr Int

openFile :: FilePath -> IO FileDescr
openFile path = MkFileDescr (someInternalCCodeThatReturnsAnInt path)

readFile :: FileDescr -> IO String
readFIle (MkFileDescr fileDescr) = someInternalCCodeThatTakesAnInt fileDescr

With a small example like this, the amount of wrapping/unwrapping might not seem all that important, but in real code, these can add up and get quite annoying! Implementing modules with abstract type synonyms is much more convenient.

Wait that’s not what you said in the title!

While I honestly believe that inside a module, abstract type synonyms are much more convenient than abstract types implemented through newtypes, they have one fatal flaw that already appears in OCaml and would be significantly exacerbated in a language with type classes:

Abstract type synonyms hide too much information.

In particular, they hide the information that an abstract type is not equal to another type.

To demonstrate this, let’s look at a (slightly contrived) example involving GADTs in both OCaml and Haskell.

type _ some_gadt =
   | AnInt : int -> int some_gadt
   | SomethingElse : 'a -> 'a some_gadt

let some_pattern_match : file_descr some_gadt -> file_descr =
    function
    | SomethingElse descr -> descr

data SomeGADT a where
    AnInt :: Int -> SomeGADT Int
    SomethingElse :: a -> SomeGADT a

somePatternMatch :: SomeGADT FileDescr -> FileDescr
somePatternMatch (SomethingElse descr) = descr

Seems pretty harmless so far, doesn’t it?

Well, if you tried to run this, you would see that only the OCaml version would complain that you haven’t provided a case for AnInt!

And if you think about it, that seems wrong! AnInt _ has type int some_gadt and you have a file_descr some_gadt here so it couldn’t possibly be AnInt _, could it?

Yes, it could!

Inside the Unix module, file_descr is equal to int, so file_descr some_gadt is also equal to int some_gadt!

The compiler needs to assume that you could have created an AnInt _ inside that module and exposed it as a file_descr some_gadt that you’re now passing to some_pattern_match.

Even worse, because the compiler cannot leak the fact that file_descr is an int internally (which would defeat the whole point of abstract types), it cannot make any assumptions about any other types! It also cannot assume that a file_descr some_gadt is not a string some_gadt or a float some_gadt, etc.

So as long as you have abstract type synonyms in the language, the compiler can never eliminate any pattern matches involving abstract types.

Newtypes avoid this issue because FileDescr and Int are always separate types. It’s just that they can be converted seamlessly without runtime costs. ¹

What was that about type classes?

In a language with globally coherent type classes, type class instances cannot be implemented on abstract type synonyms.

Global coherence means that every type class instance for a type is equal, so it doesn’t matter where you get your Eq Int instance from.

This is important for types like Haskell’s Map, a binary search tree whose structure depends on the Ord instance of its keys.

If you could create a Map with one instance of, say, Ord Int and then later access it with a different one, you could violate the internal invariants of the Map data structure.

And if you could implement type class instances on abstract type synonyms, you could do exactly that!

instance Ord int = ...

module Unix : sig
    type file_descr
    val some_map : (file_descr, string) map
    val some_descriptor : file_descr
end = struct
    type t = int
    let some_map = Map.from_list [(1, "a"), (2, "b"), (3, "c")]
    let some_descriptor = 2
end

instance Ord file_descr = ...

Map.lookup Unix.some_map Unix.some_descriptor

The Map.from_list call uses the Ord int instance defined above, but the Map.lookup call uses the second Ord file_descr instance which might be different!

Therefore, in a language like this, it would be impossible to implement any type class instances for any abstract type, including file descriptors, stacks, and many more.

And that’s why newtypes are better than abstract type synonyms!

One of the more fundamental hurdles when implementing type classes is instance resolution. A programmer might write any possible number of instances for a given class, so how do we find the one we are looking for?

For the remaining examples, let’s assume that our program contains the following instances

class C(a)

instance C(Int)
instance C(List(Bool))
instance C(List(String))
instance forall a. C((a, Int))
instance forall a. C((Bool, a))

Now, the easiest way to find an instance for a constraint, say C((String, Int)), is to linearly search through every single instance until one matches the constraint arguments.

For example, in this case, we would try (and fail) to match every single instance until we hit forall a. C((a, Int)).

Somewhat surprisingly, this is actually the strategy GHC uses.¹ But with a large number of instances, this is not exactly efficient and as it turns out, with a little effort, we can do much better!

We need to trie harder²

If you already know what tries are, the context in which you learned about them was probably very different.

The traditional use case for tries is matching sequences of text. The prime example here is text auto-completion. Imagine that our set of valid words consists of ["dog", "cat", "car", "candle", "dune", "can", "current", "dose", "bat", "category"] and the user has typed in "cat". How do we find the set of valid completions?

Just like above, we could linearly walk through the set of valid words and pick out all the ones that contain the prefix cat. For reasons that will become apparent soon, we can visualize this flat set of all valid words as a flat tree.

This is obviously pretty inefficient. If you were to try and optimize this, you might try the following: All words that contain the prefix cat start with a c, so we can group our words by their first character to immediately filter out all the ones that don’t start with a c.

With this optimization, our tree, now represented as a map from characters to sets of words, looks like this.

Cool! This already cut the number of words we need to search through roughly in half. To speed things up further, you might notice that exactly the same argument applies to the second character, as well as the third, fourth, and every one after that!

So if we apply this optimization to every character, effectively unrolling the words into fancy interlinked lists of characters, we end up with a trie!

Now, instead of being linear in the number of words times their length, our search is only linear in the size of the prefix we are looking for. In practice, where words tend to share prefixes, this turns out to be much more efficient!

Back to the world of types

So, how can we use tries for type classes? Well, first of all, we need a way to unroll our complicated nested types into a linear string of atomic units that play a similar role to the characters in our word trie.

For most types, this will be pretty straightforward. We can unroll each of them into a linear string of head constructors. You can view this transformation as a depth-first search on our type that separates every type constructor from its arguments in every step. For example, Either(List(String), Array((Int, Bool))) will be unrolled into Either(_, _) -> List(_) -> String -> Array(_) -> (_, _) -> Int -> Bool.

We can now already construct a trie to hold our instances from above.

You might even think that we could resolve instances by simply searching through the trie just like we did in our text prediction example above, but it’s not quite that simple.

Universally quantified complications

The issue is that some instances can contain universally quantified type variables! In our case, we have two such instances: forall a. C(a, Int) and forall a. C(Bool, a).

Trying to resolve, say C(Bool, Int), needs to try both instances and report an ambiguity error since both of them match.

More generally, at every inner node in our trie, there are either 0, 1, or 2 matching subtries that we need to check.

For example, looking up this instance in the trie above would traverse all of the red nodes.

This might sound like it could lead to exponential blow-up, but it actually doesn’t! In the absolute worst case, instance lookup needs to traverse every path through our trie, but that is exactly equivalent to what our naive linear search strategy did so it’s at least definitely not slower than that.

Okay, so we traverse every possible path through our trie that matches the types we are looking for. Is that it?

Not quite. Consider that variables might be used more than once in an instance. For example, given an instance forall a. C((a, a)), we need to check that the two arguments to the tuple correspond to the same type.

To achieve this, we need to remember the first type we match a variable against along a given path. If we come across this variable again, we patch the trie by inserting the (unrolled) type where the variable would be.

For example, say we have a trie with an instance for forall a. C((a, (a, Bool))). Now, matching this trie against C((List(Int), (List(Int), Bool))) follows this path. Once the traversal comes across the second occurrence of a, it locally patches the trie by replacing a with the blue path.

And that’s it! This is enough to fully implement type class resolution in languages like Haskell, Rust or PureScript.

What about entailment?

This can easily match simple instances, but what about instances like forall a. C(a) => C(List(a))? Here, C(List(a)) entails C(a), such that C(List(a)) only holds if C(a) holds. How do we take that into account?

Well, following GHC’s footsteps, this is very easy: we don’t! Type class resolution only matches the “instance head” (i.e. the part after the =>), so we only need to emit a new constraint for C(a) when we land on that instance (using our substitution to find the correct type for a).

This might seem a bit limiting and there are more elaborate systems that can use entailment information, but in an open world setting like type classes where any module might add new instances, these can have some serious subtle downsides around modularity. Only matching on the instance head is a very reasonable pragmatic choice that is enough to cover most real world cases while keeping excellent performance.

Row Polymorphism

The system we covered so far works very well for classic ML-style type systems that consist exclusively of (possibly parameterized) type constructors, but not every type system is this simple.

A common type system extension is row polymorphism, which can be used to model extensible records, polymorphic variants, and even algebraic effects. How do we include this in our trie?

The fundamental issue with row polymorphism is that the order of labels in a row does not matter. In other words, { x : Int, y : Bool } and { y : Bool, x : Int } are the same type (and hence, depending on the instantiations of a and b, even { x : Int | a } and { y : Bool | b } might be equal). Depending on the exact flavor of your type system, rows might be allowed to have duplicate labels. In that case, only the order of distinct labels is irrelevant. For example, { x : Int, y : Bool, x : String } is equal to { y : Bool, x : Int, x : String }, but not { x : String, x : Int, y : Bool }.

How could we possibly represent type class instances for these types in a trie?

The answer is actually surprisingly easy. We can treat the record with only its labels as a head constructor, similar to what we did before. Unlike before, we canonicalize rows by sorting their fields. This is especially important if we want to use the trie to detect two instances for exactly the same type (since we should probably throw an error in that case).

A beautiful property of the duplicate label semantics outlined above is that canonicalizing records with duplicate labels boils down to a stable sort since it only needs to preserve the order of duplicate labels.

For example, { y : Bool, x : Int } will be canonicalized to { x : Int, y : Bool } and subsequently unrolled to

and { x : Int, y : Bool, x : String | a } becomes

Now, when matching a type against a row head constructor like this, we move the types from the head constructor labels to the front in canonical order. This ensures that they are matched against the correct trie fields and keeps the remaining row to be matched against the extension variable if applicable.

For example, this is how one possible match could behave

Overlapping instances

Usually, requiring type class resolution to come up with a single unambiguous instance is the right choice, but sometimes it makes sense to disambiguate explicitly and let the compiler choose one instance over another. Can we do this with our trie?

Yes! In fact, since we report every matching candidate, we can perform this disambiguation entirely on the result of type class resolution without ever touching our trie. The exact rules for how to do this can be a bit subtle, but one reasonable approach is the one taken by GHC, which is documented in the fantastic GHC User’s Guide³.

Conclusion

Even if you don’t plan on implementing a programming language with type classes any time soon (why not?), there are a few things I would like you to take away from this.

• Tries are awesome!
• Picking the right data structures is incredibly important, even in domains like type checkers where they typically don’t receive that much love.
• There is a lot to be gained by applying knowledge from one area of computer science (e.g. text processing) to another (e.g. type checking)

If nothing else, this gave me a great opportunity to try out GraphViz support on my blog.

In part 3¹ of my crusade against GHC’s coherence guarantees, I have actually done it! This time we will end up with a way to generate local type class instances without any asterisks about code breaking with optimizations. On the way, we are going to end up solving the dreaded Fast Map Union Problem, combining two of my favorite Haskell tricks, and discovering a bug in a previous version of GHC.

But before we get to that, let’s start at the beginning

What even is this ‘fast Map union problem’?

Let’s pretend that Haskell did have consistent locally overridable type class instances. In that case, the interface for Map would be completely broken.

Look at the type of Data.Map.insert

insert :: Ord k => k -> v -> Map k v -> Map k v

See the issue? Map is some kind of ordered tree internally, so it depends on the Ord instance being consistent across different operations, but with local instances, we don’t have any guarantees like that.

-- This uses the regular instance for Ord Int
let map = insert (1 :: Int) 1 mempty

-- This uses a different, incompatible instance on the same map!
withLocalOrd reverseOrdInt $ insert (2 :: Int) 2 map 

If you think about this for a bit, you may come up with a solution: You can store the instance in the map. This is how most map implementations in other languages work after all.

data Map k v = MkMap (Dict (Ord k)) (ActualMapImplementation k v)

And now the type of insert doesn’t mention Ord at all anymore so everything is sunshine and roses

insert :: k -> v -> Map k v -> Map k v

…until it isn’t! Consider the type of union now

union :: Map k v -> Map k v -> Map k v

What happens if both maps use different Ord k instances? We have no way to statically ensure that they don’t. The way to solve this in practice would be to just reinsert every value from one map in the other, but that means that union is now drastically slower than it would be if we could assume that both maps use the same instance (It’s now at least linear in the size of one map vs. logarithmic in that of the smaller one).

Instance Types

Now, what we really need here is a way to statically ensure that both maps use the same Ord implementation. In a dependently typed language, one could just carry the instance dictionary in the type

data Map k v (inst :: Ord k) = ...

union :: Map k v inst -> Map k v inst -> Map k v inst

But we cannot do that in Haskell (yet?), so we need a few more tricks. What we absolutely need to do is to somehow move the used instance to the type level, so let’s start there. While we cannot directly depend on the instance value, we can define a dummy type as a stand-in.

With this new type, we can write a version of Ord that carries its concrete instance in the type. Every function with an Ord constraint should now be polymorphic over this instance parameter.

class OrdI inst a | inst -> a where
    compareI :: a -> a -> Ordering

data RegularOrdInt
instance OrdI RegularOrdInt Int where
    compareI = compare

data ReverseOrdInt
instance OrdI ReverseOrdInt Int where
    compareI x y = case compare x y of
        LT -> GT
        EQ -> EQ
        GT -> LT

And now we can finally parameterize Map over the used Ord instance!

data IMap inst k v = ...

insert :: OrdI inst k => k -> v -> IMap inst k v -> IMap inst k v
union :: OrdI inst k => IMap inst k v -> IMap inst k v -> IMap inst k v

union statically ensures that both maps agree on their instances.

The only ‘issue’ here is that we lose some inference. This is more or less unavoidable if we want multiple instances to coexist (well, more on that later). We need to tell Haskell what instance to use at some point, but it’s not that bad, since at least for IMaps, which carry the instance in their type, we only need to do this once.

let map1 = insert 1 1 $ insert 2 2 $ empty @RegularOrdInt
let map2 = insert @ReverseOrdInt 3 3 $ insert 4 4 $ empty

union map1 map2 -- Type error: Couldn't match type 'RegularOrdInt' with `ReverseOrdInt`

How do local instances fit into this?

Quite well as it turns out! We can combine two of my favorite Haskell tricks to implement them in current Haskell (You can stop pretending that they exist. We are going to implement them for real now)

Local instances might differ between different executions of the same code, so we need to make sure that the instance types can only be used locally and cannot escape. If this sounds familiar that is because there is a decent chance that you have used something similar before: runST.

ST is a monad that is used for local mutability inside pure code. You can use it to create STRefs and mutate them, just like you would in your favorite imperative language², except that Haskell, by virtue of being a pure language, needs to make absolutely sure that you never ever return an STRef from runST. Doing so would allow effects in one usage of the supposedly pure runST to affect the result of another one.

How does ST do this? It uses higher-rank types!

newSTRef :: a -> ST s (STRef s a)
runST :: (forall s. ST s a) -> a

If you have never seen this before, you’re probably quite confused right now. The type forall s. ST s a specifies that the argument to runST needs to be an ST value that works for any possible instantiation of s. Crucially for this case, this means that the s variable is, unlike a, not a type parameter of runST itself, but actually one of the arguments to runST. This is much clearer if we write runST with an explicit outer forall.

runST :: forall a. (forall s. ST s a) -> a

Now, the reason this ensures that no STRefs escape is that the s parameter of the STRef is the same as that of the containing ST monad. If you were able to return an STRef from the argument to runST, e.g. by passing something of type forall s. ST s (STRef s Int), what type would the result have? Blindly substituting would yield STRef s Int, but what is s now? Previously, s was bound by the forall in the type of the argument to runST, but that forall does not exist anymore! This is why GHC will not accept this code and complain about an ‘escaping skolem’.

We can use exactly the same trick for local type class instances to invent an instance type that only exists locally! If we can implement a function of the following type, then this will ensure that instance types cannot possibly escape.

withOrdI :: forall a b. (a -> a -> Ordering) -> (forall inst. OrdI inst a => b) -> b

Now, how do we implement this function? If you read the first post in this series, you will probably know the answer already.

At runtime, GHC represents type classes via a technique called dictionary passing. This means that a function with an Ord constraint like Ord a => a -> a -> Ordering will be turned into a function that takes an implementation of that type class as an argument (Ord a -> a -> a). This implementation, called a dictionary, is just a regular record-like data type that contains an implementation for every method.

Using GADTs, we can capture this dictionary in a value.

data OrdIDict a where
    OrdIDict :: Ord a => OrdIDict a

If we are now able to replicate the structure of this OrdIDict exactly, but with a custom record of methods, we can use unsafeCoerce to convert it to a functional OrdIDict a. By pattern matching on the result, we can release the dictionary back into a regular instance, which now contains our handwritten type class instance!

Instinctively, your definition of OrdIDict would probably look like this

data OrdIDict inst a where
    OrdIDict :: OrdI inst a => OrdIDict inst a

This is not going to work though. We need to invent a new type for inst, so OrdIDict cannot take it as a parameter. Thanks to Haskell’s support for existential types, this is not actually an issue, since we can just leave it off³.

data OrdIDict a where
    OrdIDict :: OrdI inst a => OrdIDict a

OrdI only has a single method, so it will be represented by the equivalent of a newtype record at runtime. This is erased entirely, so we do not need to build a record around our a -> a -> Ordering function.

The OrdIDict wrapper adds some indirection though, so we need to replicate that.

data FakeDict a = FakeDict a

All preparations are complete. We are ready for the magic⁴!

withOrdI :: forall a b. (a -> a -> Ordering) -> (forall inst. OrdI inst a => b) -> b
withOrdI dict body = 
    case unsafeCoerce (FakeDict dict) :: OrdIDict a of
        (OrdIDict @inst) -> body @inst

And that’s… it!

Well, not quite. If you paid very close attention, you may notice that we have no way to bind the inst type variable in the (forall inst. OrdI inst a => b) argument. This means if we put a lambda there, we cannot actually mention inst anywhere. This is easy enough to solve by introducing a Proxy value.

withOrdIProxy :: forall a b. (a -> a -> Ordering) -> (forall inst. OrdI inst a => Proxy inst -> b) -> b
withOrdIProxy dict body = 
    case unsafeCoerce (FakeDict dict) :: OrdIDict a of
        (OrdIDict @inst) -> body @inst (Proxy @inst)

Let’s try it out!

We can start with some concrete instances

map1 = insert 1 1 (empty @Int)
map2 = insert 2 2 (empty @Int)

map3 = insert 3 3 (empty @ReverseIntOrd)
map4 = insert 4 4 (empty @ReverseIntOrd)

fine1 = union map1 map2
fine2 = union map3 map4

notFine = union map1 map3 -- fails!

Looking good. Now let’s try local instances

local = withOrdIProxy compare \(Proxy @inst) -> do
    let localMap1 :: IMap inst Int Int = insert @inst 1 1 (empty @inst)
    ()

$ ghc-9.2 insttypes.hs
insttypes.hs:80:42: error:
    • Could not deduce (OrdI (*) Int) arising from a use of ‘insert’
      from the context: OrdI inst a0
    ...

Huh. That is… strange. It looks like for some strange reason, GHC defaults the inst parameter to… (*)⁵? Even if we add as many type annotations as physically possible?

If this smells like a bug in GHC, that is because it is! Or well, was.

If you run the same example with GHC 9.4, it will compile without complaining.

Now, let’s try that again

local = withOrdIProxy compare \(Proxy @inst) -> do
    let localMap1 = insert 1 1 (empty @inst)
    let localMap2 = insert 2 2 (empty @inst)

    let perfectlyFine = union localMap1 localMap2

    let notFine :: IMap RegularIntOrd Int Int = insert @inst 2 2 (empty @inst) -- fails!
    let notFine2 = union localMap1 map1 -- also fails!

    localMap1 -- fails!

Perfect!

Do we have to annotate the instance every time?

In this specific example with IMap, the number of type annotations required was quite manageable, but in code that uses OrdI like regular Ord, this is much less pleasant

min3 :: IOrd inst a => a -> a -> a -> a
min3 x y z = case compare @inst x y of -- needs a type application!
    GT -> case compare @inst y z of -- this one as well
        GT -> z
        _ -> y
    _ -> case compare @inst x z of -- same here
        GT -> case compare @inst y z of -- also here
            GT -> z
            _ -> y
        _ -> x

Used directly like this, this technique is really just Scrap your type classes with extra steps.

This is frustrating because we are just running up against GHC’s stubbornness here. There is only a single possible instance for IOrd inst a in scope, but GHC doesn’t want to choose it. Usually, this behavior might make sense, but it’s really not helpful for us.

Fortunately for us though, we are not the first to run into this issue! Polysemy, the popular effect system library, had the exact same problem. Polysemy makes it possible to define effects of the form Member Effect r over a set of effects r. The issue here is that, unlike mtl, Polysemy allows duplicate effects, so GHC again doesn’t trust that you really wanted to use the constraint from the signature and not another, currently unwritten one.

How did Polysemy solve that? They wrote a type checker plugin that disambiguates Polysemy constraints whenever there is exactly one relevant instance in scope.

This is exactly what we want, so we could probably copy most of it.

But that is a topic for a future blog post.

Conclusion

We covered quite a bit of ground there.

• We parameterized type classes over a type representing the instance
• This made it possible to statically ensure that maps can safely be merged in logarithmic time, even in the presence of local instances
• We managed to implement local type class instances that are actually safe, even in the presence of optimizations
• We discovered a bug in GHC 9.2
• There is probably a way to avoid unnecessary type applications with a GHC plugin

This is the first time in this series that I can write a conclusion without begging you to ‘please never ever use this anywhere near production’. This technique still relies on GHC’s internal type class representation (and you should always be careful around unsafeCoerce) but so does the popular reflection package, so you should be fine.

If you want to try this for yourself, you can get the code in a gist. Just make sure to use GHC 9.4 or above.

Most type classes are a bit more complex than they look, so let’s invent a new one to use as a running example.

class Pretty a where
    pretty :: a -> String

Pretty is just like Show, but with fewer methods and no preexisting instances that might get in our way.

We also need to define a dictionary type for Pretty. We could use the Template Haskell machinery from last time for this, but Pretty is simple enough to do it manually for now.

-- The newtype is important since `Pretty` only has a single method
newtype PrettyDict a = PrettyDict {
    _pretty :: a -> String
}

boringPretty :: PrettyDict Int
boringPretty = PrettyDict {
    _pretty = show
}

nicePretty :: PrettyDict Int
nicePretty = PrettyDict {
    _pretty = \x -> "✨" <> show x <> "✨"
}

With this, we could already write a few functions that use our ‘type class’, just by accepting a corresponding dictionary as an implicit parameter. This way we actually get something closely resembling local instances already!

pretty :: (?prettyInst :: PrettyDict a) => a -> String
pretty = _pretty ?prettyInst

f :: (?prettyInst :: PrettyDict a) => [a] -> String
f xs = intercalate ", " (map pretty xs)

main :: IO ()
main = do
    let ?prettyInst = boringPretty
    putStrLn $ f [1, 2, 3 :: Int]
    let ?prettyInst = nicePretty in putStrLn $ f [1, 2, 3 :: Int]

Let’s also enable optimizations, just to make sure this is actually coherent. :)

$ ghc -O2 Main.hs && ./Main
[1 of 1] Compiling Main             ( Main.hs, Main.o )
Linking Main ...
5
✨5✨

Perfect!

There is just one issue. While ImplicitParams make it almost trivial to work with local instances, we lose the ability to define regular global instances.

Whenever we want to use a function with a ?prettyInst constraint, we always have to define the instance we want to use somewhere locally in its lexical scope.

If we wanted an actual replacement for type classes with local and global instances, we would need some kind of…

Global ImplicitParams?

Remember how IP is just a regular type class? Couldn’t we just… you know… define a regular, global instance for IP?

instance IP "x" Int where
    ip = 5

λ> ?x
5

So… uh… I honestly did not expect this to work, considering GHC forbids manual Typeable or Generic instances.

Anyway, if we want to model our class with this, we can simply write global instances as instances for IP and override local instances with let ?x = ... just as we did before.

instance IP "prettyInst" (PrettyDict Int) where
    pretty = boringPretty

main :: IO ()
main = do
    putStrLn (pretty (5 :: Int))
    putStrLn (let ?prettyInst = nicePretty in pretty (5 :: Int))

$ ghc -O2 Main.hs && ./Main
[1 of 1] Compiling Main             ( Main.hs, Main.o )
Linking Main ...
5
✨5✨

Awesome! Unlike our unsafeCoerce trick last time, optimizations don’t break ImplicitParams, so this is entirely safe!

We just came up with a type class replacement that completely subsumes local, as well as global instances in a few lines of code.

It’s that simple!

It’s not that simple

If you look at the definition of IP, you will likely notice the deadly flaw in our current approach

class IP x a | x -> a where
    ip :: a

There is a functional dependency between the parameter name and its type.² This means that every parameter name can only ever be used with the same type argument and so our type class replacement can only ever have a single instance per class. The entire purpose of type classes is to overload operations for different types, so this completely defeats the point of using type classes in the first place. :/

If we try to write an instance for two separate types anyway, the compiler is going to complain as expected, since we violated the functional dependency.

instance IP "prettyInst" (PrettyDict Int) where
    pretty = boringPretty

-- Error: Functional dependency conflict
instance IP "prettyInst" (PrettyDict String) where
    pretty = PrettyDict id

When life gives you lemons

Unfortunately, since we can only have a single global IP instance, we cannot use Haskell’s regular type class dispatching mechanism to select the instance that we want.

But…

we could try and build our own, based on runtime type information. This solution will not work for all types, but it might work for all that implement Typeable.

With Typeable, we can extract a TypeRep³ from a Proxy for a given type and, thanks to typeRepFingerprint, we are able to turn this TypeRep into a Fingerprint that is unique for every type. This Fingerprint implements Ord, so we can use it as a key in a Map.

With this, we can build some machinery that selects an instance from a Map based on the runtime TypeRep of a type. The values of the Map then represent the instances for the given types.

Conveniently, we already have a way of reifying instances, so we can just store the concrete dictionaries (PrettyDicts in this case).

We have to store dictionaries of different types (e.g. PrettyDict Int, PrettyDict Bool, …), so we could try some tricks with existentials, but since we are relying on runtime type information anyway, it is easier to store them as Any and use unsafeCoerce.

newtype InstMap = MkInstMap {unInstMap :: Map Fingerprint Any}

To actually use this custom dispatching mechanism, we need to reimplement our pretty ‘method’, which now takes an InstMap as an implicit parameter and extracts the dictionary for the type used, based on its TypeRep.

pretty :: forall a. (Typeable a, ?prettyInst :: InstMap) => a -> String
pretty =
    let key = typeRepFingerprint (typeRep (Proxy :: Proxy a)) in
    case M.lookup key (unInstMap ?prettyInst) of
        Nothing -> error "pretty: No instance found at runtime"
        Just dict -> _pretty $ unsafeCoerce dict

To add a local instance to the instance map, all we have to do is to update the implicit ?prettyInst parameter.

withPretty :: forall a b. Typeable a => PrettyDict a -> ((?prettyInst :: InstMap) => b) -> b
withPretty dict x =
    let key = typeRepFingerprint (typeRep (Proxy :: Proxy a)) in
    let MkInstMap prevInst = ?prettyInst in
    let ?prettyInst = MkInstMap (M.insert key (unsafeCoerce dict) prevInst) in 
    x

Okay, so we gave up type safety, but in return, we gained the ability to override instances locally… which we could already do with just ImplicitParams without any runtime type dispatch machinery. Sounds like we are back to square one?

Recovering type safety

We have a way of locally overriding instances, but we should really make sure that instances are actually available.

How could we check this? Well, type classes are perfect for invariants like this!

If using type classes to implement a type class replacement sounds pointless, keep in mind that we don’t care about the type class methods. In fact, we don’t even need any! This way, incoherence is not an issue, since the concrete instance chosen is irrelevant.

class HasPretty a

pretty :: forall a. (Typeable a, HasPretty a, ?prettyInst :: InstMap) => a -> String
pretty = -- same implementation

Note that we didn’t change anything on the term level. The HasPretty constraint in the type purely exists to make sure that we call withPretty at some point before calling pretty.

To satisfy the HasPretty constraint in the continuation passed to withPretty, we can just use the unsafeCoerce trick from the previous post.

data LocalPrettyInst

instance HasPretty LocalPrettyInst

withPretty :: forall a b. Typeable a 
           => PrettyDict a 
           -> ((HasPretty a, ?prettyInst :: InstMap) => b) 
           -> b
withPretty dict x =
    let key = typeRepFingerprint (typeRep (Proxy :: Proxy a)) in
    let MkInstMap previousInst = ?prettyInst in
    case unsafeCoerce (Dict :: Dict (HasPretty LocalPrettyInst)) :: Dict (HasPretty a) of
        Dict -> 
            let ?prettyInst = MkInstMap (M.insert key (unsafeCoerce dict) previousInst) in 
            x

So, a function that would have a Pretty a constraint with regular classes or a (?prettyInst :: PrettyDict a) constraint with ImplicitParams, now needs a (Typeable a, HasPretty a, ?prettyInst :: InstMap) constraint.

Going global

We recovered type safety, but our approach still doesn’t offer any advantage over pure ImplicitParams, since we still don’t have a way to write global instances.

Your first thought might be to write a global instance for IP "prettyInst" InstMap and somehow populate that when defining new global instances.

Unfortunately, this doesn’t work. We could try to use a global IORef and extend it at runtime, but how would we run the code to extend that IORef? Haskell doesn’t provide a way to run IO code at module load time, so we couldn’t make sure that the map contains all relevant instances without having to populate it in main.

Instead, let’s start with an empty map.

instance IP "prettyInst" InstMap where
    ip = MkInstMap mempty

The typechecker prevents us from using this instance without further local instances since we don’t have any HasPretty instances yet.

Fortunately, telling the type checker about global instances is quite easy: We just have to implement HasPretty for the type we are writing an instance for.

Since we don’t have an actual instance yet, this would still crash at runtime; our instance map doesn’t have any implementations by default.

Consider this: In case the instance map does not contain an entry for the type pretty is called at, but it is called (meaning the HasPretty constraint was satisfied), we know that there has to be a global instance and that no local instances are in scope. Thus, crucially, there is only a single instance for HasPretty, which is a regular global instance. If there is only a single instance, we don’t need to deal with incoherence and we are able to use actual methods from HasPretty with confidence that they are coming from the global instance with or without optimizations.

What would possible methods on HasPretty look like? We still need to specify the implementation of our global instance somewhere, so this would be a perfect place to put that.

Now, whenever pretty is called and detects a runtime instance in its instance map, we know that the instance has been overridden and HasPretty is potentially contaminated, so we use the instance from the instance map directly and ignore any methods from HasPretty.

If there is no runtime instance, we know that the instance it is called at has to be a global, coherent instance and we can safely use the implementation from HasPretty to maintain coherence.

class HasPretty a where
    globalInst :: PrettyDict a

data LocalPrettyInst

instance HasPretty LocalPrettyInst where
    -- This will never be called unless someone seriously messes with things, 
    -- since `withPretty` always adds an instance to the ?prettyInst InstMap 
    globalInst = error "pretty: No instance found at runtime"

pretty :: forall a. (Typeable a, HasPretty a, ?prettyInst :: InstMap) => a -> String
pretty =
    let key = typeRepFingerprint (typeRep (Proxy :: Proxy a)) in
    case M.lookup key (unInstMap ?prettyInst) of
        Nothing -> 
            _pretty globalInst
        Just dict ->
            _pretty $ unsafeCoerce dict

This works!

If we try the example from before…

instance HasPretty Int where
    globalInst = boringPretty

main :: IO ()
main = do
    putStrLn (pretty (5 :: Int))
    putStrLn (withPretty nicePretty (pretty (5 :: Int)))

$ ghc -O2 Main.hs && ./Main
[1 of 1] Compiling Main             ( Main.hs, Main.o )
Linking Main ...
5
✨5✨

… everything works as expected, even with optimizations!

There is actually not much boilerplate involved in this technique, compared to regular type classes and instances.

The main limitation is that types used in instances all have to implement Typeable, so we can only use this for relatively simple instances.

Defining a class is quite a bit more verbose since we have to define a dictionary type, a HasX class to carry the global instance, a global instance for the associated implicit parameter as well as functions to apply and override the active instance.

To use our running example, the class definition

class Pretty a where
    pretty :: a -> String

becomes

newtype PrettyDict a = PrettyDict {
    _pretty :: a -> String
}

class HasPretty a where
    globalInst :: PrettyDict a => a

pretty :: forall a. (Typeable a, HasPretty a, ?prettyInst :: InstMap) => a -> String
pretty =
    let key = typeRepFingerprint (typeRep (Proxy :: Proxy a)) in
    case M.lookup key (unInstMap ?prettyInst) of
        Nothing -> 
            _pretty globalInst
        Just dict ->
            _pretty $ unsafeCoerce dict

data LocalPrettyInst

instance HasPretty LocalPrettyInst where
    globalInst = error "pretty: No instance found at runtime"

withPretty :: forall a b. Typeable a => PrettyDict a -> ((HasPretty a, ?prettyInst :: InstMap) => b) -> b
withPretty dict x =
    let key = typeRepFingerprint (typeRep (Proxy :: Proxy a)) in
    let MkInstMap prevInst = ?prettyInst in
    case unsafeCoerce (Dict :: Dict (HasPretty LocalPrettyInst)) :: Dict (HasPretty a) of
        Dict -> 
            let ?prettyInst = MkInstMap (M.insert key (unsafeCoerce dict) prevInst) in 
            x

Crucially, though, the boilerplate involved in using these overridable instances is pretty minimal and most of the boilerplate when defining these ‘classes’ could be automated with TemplateHaskell.

New global instances only have to implement HasPretty, which is a tiny bit less ergonomic than Pretty, since we have to implement the dictionary, not the methods and there are no default implementations.

instance HasPretty Int where
    globalInst = PrettyDict {
        _pretty = show
    }

The only difference between a function that uses our overridable pretty and one that uses the regular Pretty type class is in the constraint, which changes from Pretty a to (Typeable a, HasPretty a, ?prettyInst :: InstMap).

We could try to factor this out to a type synonym.

type Pretty a = (Typeable a, HasPretty a, ?prettyInst :: InstMap)

Thereby completely eliminating any additonal boilerplate when using pretty!

Let’s rewrite pretty with a Pretty a constraint instead of the more complicated (Typeable a, HasPretty a, ?prettyInst :: InstMap). After all, Pretty is just a type synonym, so this should mean exactly the same thing, right? …right?

It all comes tumbling down

pretty :: Pretty a => a -> String
pretty = ...

λ> :t pretty
pretty :: (HasPretty a, Typeable a) => a -> String

Uh oh. The ?prettyInst :: InstMap constraint just… disappeared?

What happened here, is that when resolving⁴ the type synonym, GHC tried to simplify the constraint and removed the monomorphic ?prettyInst :: InstMap constraint, since an instance was found in the global context.

This obviously sounds like a bug, but I am not certain that it actually is. In fact, the real bug is probably that we were able to define a global instance for IP in the first place.

Okay, we are unable to factor out the (Typeable a, HasPretty a, ?prettyInst :: InstMap) constraint with a type synonym. Since we have a custom HasPretty class anyway, we could try to include these as superclasses in the style of Opaque constraint synonyms instead.

class (Typeable a, IP "prettyInst" InstMap) => HasPretty a

…except this doesn’t work. GHC does not allow implicit parameters in superclasses, even if we explicitly write them as IP class constraints.

This is a reasonable restriction because the time at which dictionaries with super classes are constructed can be quite unpredictable, so an implicit parameter superclass constraint will probably not contain the intended value, but it is annoying since we have to keep the ?prettyInst :: InstMap constraint around.

We could at least try to factor out Typeable though.

class Typeable a => HasPretty a where
    ...

This compiles and even runs correctly!

…as long as we compile with optimizations.⁵

So, factoring out the (Typeable a, HasPretty a, ?prettyInst :: InstMap) constraint is not an option. Is there anything else we cannot do?

f :: (Typeable a, HasPretty a, ?prettyInst :: InstMap) => a -> String
f = pretty

g x = f x

λ> :t g
g :: (Typeable a, HasPretty a) => a -> String

main :: IO ()
main = do
    -- I am using instances for `Bool` here since we haven't defined a 
    -- global instance for `HasPretty Bool` yet.
    putStrLn (withPretty (PrettyDict @Bool show) (f True))
    putStrLn (withPretty (PrettyDict @Bool show) (g True))

$ ghc Main.hs && ./Main
[1 of 1] Compiling Main             ( Main.hs, Main.o )
Linking Main ...
True
Main: pretty: No instance found at runtime
CallStack (from HasCallStack):
  error, called at Main.hs:55:18 in main:Main

Oh, come on!

As it turns out, when inferring the type for g, GHC omits the implicit parameter constraint and instead hard wires the empty instance map from the global instance.

withPretty still inserts a HasPretty instance, so the compiler cannot stop us from calling g and crashing at runtime.

Conclusion

• We are able to replace type classes with overridable ImplicitParams and runtime type information based dispatch.
• We can recover type safety, by using fake constraints for an empty class so that incoherence is not an issue.
• To get proper global instances, we can extend the previously empty class with a base implementation. We only ever use this implementation if we are absolutely sure no local instance exists, so this is also safe.
• Unfortunately, the global ImplicitParams instance makes ?prettyInst constraints extremely brittle and mistakes like forgetting a type signature can remove the parameter and lead to runtime crashes.

To safely use this, we always have to make sure to

• type out the entire (Typeable a, HasPretty a, ?prettyInst :: InstMap) constraint
• write a type signature whenever it might include ?prettyInst

Now, should you ever use any of this in anything that you might possibly not want to break?

Of course not. Global implicit parameters seem to be mostly uncharted territory and I’m pretty sure their mere existence constitutes a bug.

Still, screwing around with broken features and pushing the limits of Haskell is fun. I had a blast writing this and I hope it was enjoyable to read as well! Maybe you even learned something today?

After all, (+) is an associative binary operation, and 0 acts as a unit element.

instance Semigroup Int where
    (<>) = (+)
instance Monoid Int where
    mempty = 0

The reason, as you will have learned is that this is not the only possible instance for Monoid Int.

The following instance is, in fact, just as valid.

instance Semigroup Int where
    (<>) = (*)
instance Monoid Int where
    mempty = 1

You might also be aware, that the way to work around this is to declare newtype wrappers and to wrap and unwrap all Ints every time the Monoid instance is needed.

newtype Sum a = Sum {getSum :: a}
newtype Product a = Product {getProduct :: a}

instance (Num a) => Semigroup (Sum a) where
    (Sum x) <> (Sum y) = Sum (x + y)
instance (Num a) => Monoid (Sum a) where
    mempty = Sum 0

instance (Num a) => Semigroup (Product a) where
    (Product x) <> (Product y) = Product (x * y)
instance (Num a) => Monoid (Product a) where
    mempty = Product 1

λ> getSum $ foldMap Sum [1..10] <> Sum 5
60

There is a bit of boilerplate involved in defining the newtypes and corresponding instances, but what is hard to swallow is that quite a bit of boilerplate has to be included at every single use site.¹

If Haskell had local instances, this would not be an issue since we would not be forced to commit to a single instance and could just tell the compiler the instance we want without having to constantly wrap and unwrap everything.²

Introducing Dict

GHC uses a technique called dictionary passing to compile typeclass dictionaries. This means that in Core (GHC’s intermediate language), => is turned into ->. In other words, constraints become arguments, called dictionaries.

Why is that useful to know? Well, while there is no way to directly access or construct these dictionaries, we can reify them with Dict.

data Dict (c :: Constraint) where
    Dict :: c => Dict c

Because the constraint c appears in the type signature of the Dict constructor, the constructor stores the corresponding dictionary, and whenever it is scrutinized in a pattern match, the constraint is made available.

Unfortunately, even with Dict, there is no way to construct a dictionary without defining an instance first.

The only way to construct a ‘local’ instance then is to define an instance for a newtype wrapper, but if we create a Dict from that instance, we cannot use the newtype Dict for our original type, because Dict (Monoid Int) and Dict (Monoid (Sum Int)) are entirely separate types to the typechecker.

We hit quite the wall there. We know we could use the Dict for our newtype, and we know it would be safe³ because newtypes are erased at runtime, but the typechecker doesn’t allow us to use a newtype Dict to get an instance for the original type.

If there was just some way to bypass the typechecker…

I solemnly swear I am up to no good

Luckily for us: there is!

unsafeCoerce :: forall a b. a -> b lets us bypass the typechecker by treating a value of any (lifted) type as a value of any other (lifted) type.

This is probably one of the most dangerous, if not the most dangerous function in GHC’s arsenal. If you’re not careful, you can easily end up with segmentation faults.

We know what we’re doing though, so let’s try it out!

monoidSumDict :: Dict (Monoid (Sum Int))
monoidSumDict = Dict

monoidIntDict :: Dict (Monoid Int)
monoidIntDict = unsafeCoerce monoidSumDict

-- If we didn't include the type signature, GHC would be confused about the type of number we're using
λ> case monoidIntDict of Dict -> fold [1..10] <> (5 :: Int)
60

Perfect! We just created an instance of Monoid Int, that only exists if we pattern match on monoidIntDict. This sounds a lot like local instances to me.

Let’s simplify this

What we have so far is already pretty cool, but having to write out a pattern match every time is a bit inconvenient.

Fortunately, we can easily factor out the pattern match by turning it into a function.

withDict :: Dict c -> (c => a) -> a
withDict d x = case d of Dict -> x

λ> withDict monoidIntDict $ fold [1..10] <> (5 :: Int)
60

That (c => a) argument might look a bit strange, but this is exactly what we’re trying to do: Take a value or function with a constraint and remove that constraint by inserting the instance stored in our Dict.

We can do even better. The only way to construct one of our ‘local’ Dicts is to create a Dict for a newtype and cast that to a Dict for the original type using unsafeCoerce, but users of our library really shouldn’t have to write their own Dict definition, let alone use unsafeCoerce.

withLocal :: forall c1 c2 d. c1 => (c2 => d) -> d
withLocal x = case c2Dict of Dict -> x
    where
        c1Dict :: Dict c1
        c1Dict = Dict
        c2Dict :: Dict c2
        c2Dict = unsafeCoerce c1Dict 

λ> withLocal @(Monoid (Sum Int)) @(Monoid Int) $ fold [1..10] <> (5 :: Int)
60

Now, all that users have to do is supply the right type applications and withLocal is going to do everything else for them. Nice!

Hey Google, what’s a segfault?

λ> withLocal @(Eq Bool) @(Num Int) $ (-1 :: Int) + 2
fish: Job 1, 'ghci unsafeCoerceDict.hs' terminated by signal SIGSEGV (Address boundary error)

Oh no⁴…

We just used unsafeCoerce to cast a Dict (Eq Bool) to a Dict (Num Int). We really shouldn’t be able to do this.

The issue here is that withLocal places no constraints on the — well — constraints (c1 and c2). In reality, we need both constraints to contain the same typeclass and to only differ in the argument to that class.

Let’s do that.

withLocal :: forall c a b d. (c a) => (c b => d) -> d
withLocal x = case cbDict of Dict -> x
    where
        caDict :: Dict (c a)
        caDict = Dict
        cbDict :: Dict (c b)
        cbDict = unsafeCoerce caDict 

Note that we did not change anything about the implementation. We just constrained its type signature.

Unfortunately, withLocal can still segfault because there are still no constraints on a and b. We could, for instance, still try to convert a Monoid String to a Monoid Int.

Why did this even work before?

The reason why this function is safe on Sum Int and Int is that Sum Int is just a newtype wrapper over Int, and newtypes are completely erased at runtime. So a function of type Sum Int -> b really becomes a function of type Int -> b at runtime.

Thus we can safely⁵ cast it to Int -> b using unsafeCoerce.

String and Int don’t have the same runtime representation, so we cannot safely cast Dict (Monoid String) to Dict (Monoid Int).

Fortunately for us, Haskell does actually provide a way to constrain a function to types with the same runtime representation: Coercible!

If we adjust our function to include a Coercible a b constraint, we finally end up with a safe implementation that doesn’t segfault!

withLocal :: forall c a b d. (c a, Coercible a b) => (c b => d) -> d
withLocal x = case cbDict of Dict -> x
    where
        caDict :: Dict (c a)
        caDict = Dict
        cbDict :: Dict (c b)
        cbDict = unsafeCoerce caDict 

λ> withLocal @Monoid @(Sum Int) @Int $ fold [1..10] <> (5 :: Int)
60

Note that we still had to use unsafeCoerce instead of coerce. Just because a can be coerced to b, doesn’t mean GHC will allow you to cast Dict (c a) to Dict (c b).

Expanding

What we have so far is already pretty cool, but we can do even better.

So far, all our local instances were limited by us having to write an instance for a newtype wrapper and so our instances could not include entirely arbitrary functions.

We couldn’t, for example, declare a local function depending on a local variable and use that in an instance, because instances have to be written at the top level and therefore can’t include local variables.

Fortunately, by selling a bit more of our soul to the type checker, we can work around this limitation!

At runtime, dictionaries (not Dicts) are really just regular data types, so there is no reason, why we shouldn’t be able to fake them with unsafeCoerce.

Note, that Dict actually stores the runtime dictionary as a lifted field, so if we want to coerce to Dict, we need to add a layer of indirection.

data FakeDict a = FakeDict a

Now for the runtime dictionary, let’s look at the definition of the Eq typeclass.

class Eq a where
  (==) :: a -> a -> Bool
  (/=) :: a -> a -> Bool
  {-# MINIMAL (==) | (/=) #-}

Eq has two methods (==) and (/=), so our datatype also has to have two fields with matching types.

data EqDict a = EqDict {
        _eq  :: a -> a -> Bool
    ,   _neq :: a -> a -> Bool
    }

Now we need a function to make unsafeCoere a little less unsafe.

withFakeDictUnsafe :: forall c d a. d -> (c => a) -> a
withFakeDictUnsafe d x = case unsafeCoerce (FakeDict d) :: Dict c of
    Dict -> x

This already works for simple classes like Eq, but right now we can’t handle classes with superclasses like Monoid, because we have no way of storing the superclass dictionary in our fake dictionary.

In order to include the dictionary, we have to expand our MonoidDict to a GADT.

data MonoidDict a where
    MonoidDict :: Semigroup a => {
        _mempty  :: a
    ,   _mappend :: a -> a -> a
    ,   _mconcat :: [a] -> a 
    } -> MonoidDict a

And… that’s it!

We can now actually write useful functions that we couldn’t just emulate by wrapping everything in a newtype.

As an example, let’s consider a function that (locally) implements a Monoid instance for a type, which only implements Semigroup, based on a provided default argument for mempty.

withSemigroupAsMonoid :: forall a b. Semigroup a => a -> (Monoid a => b) -> b
withSemigroupAsMonoid d = withFakeDictUnsafe @(Monoid a) (MonoidDict {
        _mempty  = d
    ,   _mappend = (<>)
    ,   _mconcat = foldr (<>) d
    })

We couldn’t use a newtype instance, since withSemigroupAsMonoid uses the function parameter d in its instance definition.

Template Haskell

Writing all these Dict types by hand is not just annoying, but also quite dangerous because they are not automatically kept in sync with the corresponding type classes, so if one of those changes and we forget to update the Dict, the types are not actually compatible anymore.

We can use some TemplateHaskell to automate the process and (hopefully) avoid further segfaults.

My experience with TemplateHaskell is pretty limited, so I’m not going to pretend like this is a great implementation.⁶

makeDict :: Name -> Q [Dec]
makeDict cname = do
    reify cname >>= \case -- (1)
        ClassI cdec is -> case cdec of
            ClassD cxt cname tvs _ meths -> pure [
                        dataCon [] dname tvs Nothing [ForallC (map (addSpecificity SpecifiedSpec) tvs) cxt 
                            $ RecGadtC [dname] (map methodToVarBangType meths) appliedFakeType] [] -- (2)
                    ]
                where
                    dataCon = case (meths, cxt) of
                        ([_], []) -> \cxt name tvs k [cs] ds -> NewtypeD cxt name tvs k cs ds -- (4)
                        _ -> DataD
                    dname = mkName $ nameBase cname <> "Dict" -- (3)
                    
                    methodToVarBangType (SigD n t) = (mkName ("_" <> nameBase n), Bang SourceNoUnpack NoSourceStrictness, t)
                    
                    appliedFakeType  = foldl AppT (ConT dname) (map (VarT . tyVarName) tvs)
                    appliedClassType = foldl AppT (ConT cname) (map (VarT . tyVarName) tvs)

                    addSpecificity s (PlainTV n _) = PlainTV n s
                    addSpecificity s (KindedTV n _ k) = KindedTV n s k

                    tyVarName (PlainTV n _) = n
                    tyVarName (KindedTV n _ _) = n
            _ -> fail $ "Not a class: " <> show cname
        _ -> fail $ "Not a class: " <> show cname

The important steps are these:

1. We get the class definition using reify
2. We can use that definition to construct a record GADT (RecGadtC) with one field for every class method.
3. The new GADT is called <ClassName>Dict.
4. If there is only a single method and no superclass, we construct a newtype instead. Note that this step is not just an optimization, but absolutely crucial, since a data constructor has one more level of indirection than a newtype, and confusing the two would lead to a segfault.

We actually get another benefit from generating our instance. Since we know, that using withFakeDictUnsafe with our generated MonoidDict is safe, we can use a (non-exported) type class and a function withFakeDict to constrain arguments to safe (i.e. generated) dictionaries.

class FakeDictFor (c :: Constraint) (d :: Type) | d -> c

withFakeDict :: forall d c a. FakeDictFor c d => d -> (c => a) -> a
withFakeDict = withFakeDictUnsafe

makeDict :: Name -> Q [Dec]
makeDict cname = do
    {- ... -}
    [d|instance FakeDictFor $(pure appliedClassType) $(pure appliedFakeType)|]
    {- ... -}

Incoherence

Unfortunately, both withLocal and withFakeDictUnsafe have a pretty serious flaw. Usually, whenever we use a typeclass method in Haskell, there are essentially two possibilities: either no instance exists or there is exactly one and the compiler picks that one. This is called Coherence and is also the reason why all in-scope typeclass instances are always exported from a module.

The issue with our functions is that in case there is already an instance for the typeclass, they introduce a second instance and break the compiler’s Coherence assumption.

As an example, let’s say we want to introduce a local instance for Show Int. If we do this, using withLocal⁷, which instance is the compiler going to pick? Let’s find out!

newtype FancyShow a = FancyShow a
instance Show a => Show (FancyShow a) where 
    show (FancyShow x) = "⭐" <> show x <> "⭐"

main = withLocal @Show @(FancyShow Int) @Int $ print (5 :: Int)

$ ghc unsafeCoerceDict.hs && ./unsafeCoerceDict
[1 of 1] Compiling Main             ( unsafeCoerceDict.hs, unsafeCoerceDict.o )
Linking unsafeCoerceDict ...
⭐5⭐

Nice! It seems like we can override instances using withLocal. Let’s try that with optimizations

$ ghc -O unsafeCoerceDict.hs && ./unsafeCoerceDict
[1 of 1] Compiling Main             ( unsafeCoerceDict.hs, unsafeCoerceDict.o )
Linking unsafeCoerceDict ...
5

Oh no… optimizations can change the semantics of our program by picking the original instance, that we tried to override. We really don’t want that.

To make matters worse, there is no way to prevent incoherent usage without having to include Template Haskell at call sites, since there is no way to write a type like Not (Eq a) => (Eq a => b) -> b.

It’s not that bad though. As long as we make sure to never try to override existing instances, we are safe.

ImplicitParams

withFakeDict might remind you of a different Haskell feature, namely ImplicitParams. And indeed, we can directly interoperate with ImplicitParams using withFakeDict.

An implicit parameter constraint like

f :: (?x :: Int) => Int
f = ?x + 1

is really just syntactic sugar for

f :: (IP "x" Int) => Int
f = ip @"x" + 1

where IP is a regular type class defined in GHC.Classes.

What’s really cool about this is that we can actually define an IP constraint using withFakeDict.

So instead of

let ?x = 5 in f

we can write

withFakeDict @(IPDict "x" Int) (IPDict {_ip = 5}) f

and get the exact same behavior!

This means that withFakeDict is strictly more powerful than ImplicitParams, but it also shares ImplicitParams’ somewhat famous issues.

Configurable trace

Debug.Trace.trace can be a very useful function for quick debugging. Want to know what this intermediate expression evaluates to? Just write it to stderr using trace. Want to know what values this function is called with? You can use trace for that.

f :: A -> B
f x | trace ("x = " <> show x) False = error "unreachable"
f x = ...

Unfortunately, trace is not really suited for slightly more permanent tracing, since there is no way to turn it off or to change the target it writes to.

If we wanted to improve trace, we would have to somehow pass a configuration without actually passing it manually to every single function. Sounds a lot like type classes to me!

Let’s try that. We should also probably use Text instead of String, while we’re at it.

class Trace where
    trace :: Text -> a -> a

To make filtering easier, we should probably also accept some kind of trace level. We could just accept an integer, but parameterizing our class over the type of the trace level is more general.

class Trace lvl where
    trace :: lvl -> Text -> a -> a

Cool. Functions that want to perform logging now need an additional Trace lvl constraint, that supplies the actual implementation.

How do we pick the implementation though? If you’ve paid attention so far, the answer should be obvious: We construct a fake dictionary using withFakeDict.

class Trace lvl where
    trace :: lvl -> Text -> a -> a

makeDict ''Trace

runTraceStderr :: (Trace lvl => a) -> a
runTraceStderr = withFakeDict (TraceDict {
        _trace _ = Debug.Trace.trace
    })

ignoreTrace :: (Trace lvl => a) -> a
ignoreTrace = withFakeDict (TraceDict {
    _trace _ _ x = x
})

One issue that might still come up is that someone could theoretically define a top-level instance of Trace lvl, which would introduce incoherence and completely break our system. To prevent that, we can hide the actual implementation in a class _Trace, that we don’t actually export. We can then define a type synonym Trace that we do export. This way, users of our library can still reference Trace through our type synonym, but cannot define top-level instances since instances cannot be defined for type synonyms of type classes.

class _Trace lvl where
    trace :: lvl -> Text -> a -> a

makeDict ''_Trace

type Trace = _Trace

runTraceStderr :: (Trace lvl => a) -> a
runTraceStderr = withFakeDict (Trace_Dict {
        _trace _ = Debug.Trace.trace
    })

ignoreTrace :: (Trace lvl => a) -> a
ignoreTrace = withFakeDict (Trace_Dict {
    _trace _ _ x = x
})

Nice! We just defined a fairly extensible little tracing library in less than 20 lines of code.

Here is why this is a good application of fake local instances

• There is no reason to manually implement the Trace type class, so we were able to hide it completely and fully prevent incoherence.
• In case we made a mistake or this whole approach is fundamentally flawed and GHC decides to pick the wrong instance, nothing major breaks. (You can never be entirely sure with unsafeCoerce tricks like this)
• This is really easy to implement, and much less limited than most alternative approaches (Logging monads/effects, global IORefs, …)

Conclusion

Now, what did we learn from all of this?

• It is possible to transfer instances between newtypes.
• This approach can be expanded to allow the inclusion of arbitrary functions as instance methods.
• All segfaults stemming from non-unsafe functions can be avoided and it is possible to generate most boilerplate.
• Incoherence, stemming from multiple instances being available at once, is an issue.
• ImplicitParams can be emulated with local instances.
• A tiny extensible tracing library is a pretty cool application of local instances.

Does this mean, you should throw all your newtypes out of the window? No.

Does this mean, you should use the code from this article in production? Probably not. You should really know what you’re doing if you want to use anything in production that is based on unsafeCoerce. That said, if you want to try this out for yourself, the code is available in a small library on github, including trace.

Ultimately, I hope that you learned a nice little trick today. You never know when it might come in handy.