Here is a small example of aggressive refactoring in Haskell. I am in the codebase of a compiler for a small smart contract language, and I'm replacing occurrences of Integer with occurrences of Word256, since the code generator in question targets Ethereum which has 256-bit word sizes.

The compiler was originally made with Integer, and in some cases its very own Word256 which was made in a crude way. Integer because this is a very convenient data type in Haskell, even though arbitrary precision in this case is actually wrong, and the crude Word256 because it seemed simpler to make this type rather than import a library.

But now this is no longer convenient, so I've decided to use Word256 of the data-dword library since that's what Hevm uses. There are alternatives: largeword and wide-word, but the important part for now is interoperability.

And here is the type error I'd like to show:

src/Lira/Backends/Evm/EvmCompiler.hs:695:22: error:
    • Couldn't match expected type ‘Integer’
                  with actual type ‘Data.DoubleWord.Word256’
    • In the first argument of ‘push’, namely ‘i’
      In the expression: push i
      In the expression: [push i]
    |
695 |   IntVal  i -> [push i]
    |                      ^

Because IntVal i now contains a Word256 and push was designed for Integer, the types no longer align. Looking at push:

push :: Integer -> EvmOpcode
push = PUSHN . words'
  where
    words' :: Integer -> [Word8]
    words' i | i < 256 = [fromIntegral i]
    words' i           = words' (i `div` 256) ++ [fromIntegral $ i `mod` 256]

There is no logic in this function that prevents it from operating on Word256 rather than Integer. In fact, rather than change the function, just loosen the type signature:

-push :: Integer -> EvmOpcode
+push :: Integral i => i -> EvmOpcode
 push = PUSHN . words'
   where
-    words' :: Integer -> [Word8]
+    words' :: Integral i => i -> [Word8]
     words' i | i < 256 = [fromIntegral i]
     words' i           = words' (i `div` 256) ++ [fromIntegral $ i `mod` 256]

Doing an aggressive refactor like changing a base type in the codebase requires hundreds of changes. But when their nature is like this, I can safely leave this change be and proceed to the next type error.