History of DH (Dependent Types in Haskell) contributions

I’ll be soon publishing a task breakdown for DH. In addition to the planned changes, I decided to include the recent history of related work (2018–2024) in the form of links to specific proposals, issues, and commits.

Here’s an example of what a single section is going to look like:

and there will be about 50 of such sections.

However, as the volume of GHC commits and issues is too high for me to go through all of them, I had to limit the scope and focus on my own work.

If you have any DH-related contributions that you want represented, please let me know and I’ll try to find a place to include a reference.

43 Likes

The page is now public at ghc.serokell.io/dh, and the task graph can be downloaded as a vector image from ghc.serokell.io/roadmap.svg

I intend to update this page continuously as we make more progress. All feedback is welcome, as well as any questions.

28 Likes

This is a thing of beauty; thank you for taking the time to make it!

5 Likes

A notable omission in the task graph has caught my eye: We need to figure out the interaction between type families, associated types, and dependent types. This is a very foundational point that is both very nuanced and has long lasting consequences. If there is pre-existing agreement or even discussion of this I haven’t seen it.

Just to name a few nuances: Type families on the surface look like promoted functions but their equations aren’t (always) matched from top to bottom, and the equations can repeat quantified variables (example). That makes them more similar in spirit to conservatively extending a theory by adjoining a functional symbol. They use “evaluation by unification”, whereas “normalization by evaluation” is standard in dependent types. Associated types are currently just type families with a cosmetic attachment to a parent type class. However in a dependently typed language we would instead have them as Type-kinded fields in the class dictionary.

5 Likes