Instead of a custom Solver monad, the new Type.Solve code uses plain IO and threads some state around. This means that some things (env, rank, pools) can just be “environment variables” whereas the data that really is stateful is threaded through. Benefits include: - No need to allocate new State objects when using a new env. Just pass the new env down instead. - State holds three items, not six. Generates less garbage. - No indirection between using IO. No more liftIO anywhere. - When operating on a list, just foldM and accumulate state. No need for traverse_ or mapM_ or whatever other tricks to try to avoid allocating pointless intermediate lists. This change also required some supporting changes in Type.Unify and Type.Constraint to minimize the overall allocations needed on the successful path of unification. Do not want to allocate when solving constraints unless an error occurred. As a final reflection, I find it frustrating that the simpler code (without monad transformers, custom monads, CPS’d monads, etc.) is better in a bunch of ways. It feels like the ecosystem offers you a tool that ultimately makes your code harder to understand and less performant. This is a good lesson.