• Forbid generic templates in the DAML preprocessor for now since we haven’t yet figured out to support them with those changes.
• Desugar typeclasses to structural records in LF. This allows us to combine instances from different SDKs.
• Move data types from daml-stdlib to separate packages with stable hashes. This makes sure that the hash of things like Either, Tuple2, … doesn’t change. We might want to treat this like a single package for GHC to avoid an explosion of packages.
• Split up the template typeclass and change Template to a type synonym. This allows us to extend the template typeclass with more methods.
• Extend LF conversion to handle the new typeclasses.
• Change template desugaring in our GHC fork to target the new typeclasses.
• Remove support from LF conversion for the existing syntax.
• Extend DAML-LF with type synonyms and generate type synonyms for each structural record corresponding to a typeclass.

Next, the changes to handling of data-dependencies (long-term, we might want to remove the separation and treat everything as a data-dependency but I would suggest to do this at the very end if at all).

• When importing a dependency, we look for typeclass instances in the DALF. We treat everything that has the type corresponding to a type synonym as a typeclass. For each instance, we create a dummy instance. Every reference to the typeclass dictionary will be rewritten to the old dictionary.

• Adapt daml migrate to a world without generic templates and enable tests for it in the daml assistant integration test suite again.

I’ve probably forgotten some things so feel free to extend this list.

Open Questions

• Which things to need to be kept intact while we do those changes? I’m somewhat tempted to say that we can break data-dependencies since that isn’t all that useful in the current state and it makes it harder to do the rest incrementally?

• Do we really need type synonyms? It seems like the only case where we need type synonyms is to figure out which typeclasses exist. Could we instead create a proxy value with the structural record as the type parameter for each typeclass? So for the Ord typeclass we would create something like ord : a -> TypeClassProxy [("compare", a -> a -> Bool)].

  Answering my own question: Yes, we need this so that we know what to translate the TyCon to at the usesite where we do not have access to the typeclass definition (since it can be an AbstractClass for dependencies). Given that we don’t support ConstraintKinds, we probably don’t need to support partial application of the synonym. With constraint kinds, we could end up with class C a b which creates synonym C a b = tuple … and we might have to translate C a.