Synthesizing `RuntimeRep`-indexed type class instances in a GHC plugin to simulate monomorphization

simonpj:

Make a copy of the source code for f, specifically for Double#, and compile that. Now we have two versions of f. That’s fine but it’s hard to know which types to specialise f for

I’ve been thinking about this recently and I am exploring this option. Instead of generating all possible options in advance, we could generate the code only at call sides.

A further problem, then, is that the function may be called at the same type in different places. You’d want to share specializations. I want to see if we could do two passes:

1. compile the package while keeping the runtime rep polymorphic functions as holes (in the sense of backpack). Also collect info on all calls.
2. Generate a module with all specialisations for the calls we found and instantiate the hole with that module.

This does only work if we can rule out existential quantification and polymorphic recursion. To address fhat, I am also thinking about extending the type system to let us specify that a certain type variable must be monomorphised. That could be used to rule out problematic polymorphism.

This also could be nice for certain other type classes like PrimMonad or even Monad in general, which often see huge benefits from specialization, so you want to specialise those even if it leads to larger binaries and longer compile times.