Journal entry for June 5, 2023

I’ve been reading Sylvain Henry, John Ericson, and Jeffrey M. Young’s “Modularizing GHC” paper which discusses the current state of the GHC code base and how it might be improved. As of now the code has become inflexible due to new work (necessarily?) choosing the path of lowest friction to add features. I imagine doing thorough refactorings when you’re on a PhD thesis time budget and a lot of others are also trying to add features isn’t easy.

The authors propose that the principles of Domain Driven Design will be helpful to define what good improvements to the current state would look like:

• Ubiquitous language: use consistent and precise terminology in code and documentation, and make it apparent at type-level.
• Domain isolation with layered architecture: use layering to avoid spaghetti or lasagna code.
• Supple design: make code “a pleasure to work with, inviting to change”.

These all sound like great principles, and having this as a check-list that cannot be circumvented for any newly checked in code would be a major help. I’ve tried to use the GHC API while playing around with writing HLS plugins and the documentation and names used were extremely confusing. It might be impossible to start something from scratch without looking at existing examples and without external help. Not something that ought to be the case in a code base related to functional programming.