The Haskell ecosystem has accumulated a wealth of developer tools over the years. Some of them, such as Hoogle and HLint, have existed for nearly two decades, while others, such as the Haskell Language Server and Retrie, are much more recent. GHC has changed substantially in that time, and this presents a significant challenge to tooling authors saddled with the burden of keeping their tools up to date. Too often, a promising new Haskell utility simply disappears because it’s too difficult to maintain. This is unfortunate, as programmers’ expectations for language tooling have only continued to rise; for many prospective users of Haskell, robust tools are table stakes.
At the heart of all Haskell tooling is, of course, GHC itself, which has become the de facto source of truth for both the definition of the Haskell language and many key packaging concerns. In theory, GHC has precisely the information many tooling authors need: it knows how to parse, typecheck, and transform Haskell code, and it knows a great deal about its structure. Sadly, initiatives to expose this information to tool authors have been challenging. Though attempts have been made to equip GHC with APIs for doing more than just building Haskell code, such as the plugin API and the API to GHCi, the APIs are complex, expose users to GHC internals, and are not particularly stable. More restricted avenues for providing information to tool authors, such as HIE files, have proven more successful, but they are a far cry from a cohesive story for how tool authors ought to get at information about Haskell programs.
It is for the above reasons that I am pleased to announce I will be leading the Haskell Foundation’s new GHC API stability initiative. As the project’s coordinator, my aim is explicitly not to dictate a design to be implemented but to facilitate the necessary conversations and distill whatever conclusions result into a concrete plan. This is no small task: any workable design must weigh the needs of tool authors, the maintenance burden placed on GHC developers, and the fundamental challenges of designing stable APIs in Haskell more broadly, among other things. Our plan of attack is to start small. We cannot hope to address all the complex needs of, say, typechecker plugins or HLS right out of the gate, but we believe we can provide real, immediate utility to many existing tools. This requires being deliberate about what we choose to support, starting from the needs of tooling authors rather than from the set of features that are easy to expose from the GHC codebase. Our goal is not to produce a totalizing model for how all GHC functionality can be or even ought to be exposed but merely a useful kernel we can commit to that can be grown and extended over time.
In the coming weeks, I will be reaching out to potential project stakeholders—mainly GHC developers and tool authors—to both collect perspectives and assemble a minimal working group. I do not expect this group’s work to be terribly glamorous: our immediate objective is to simply catalog existing needs and assess which ones we might practically address. Once the landscape is clear, we will begin the laborious process of exploring and weighing the design space of potential solutions with as pragmatic and realistic an eye as we can manage. I do not expect this to happen particularly quickly, but a major part of my role is to make sure discussions stay on track. Throughout the process, I’ll be posting updates to the community here on Haskell Discourse to keep you informed about our progress and to provide opportunities for a broader discussion.
If you have experience in this area and are interested in participating, by all means reach out to me at alexis@haskell.foundation. Your knowledge and wisdom are invaluable, and understanding your needs is crucial to this project’s success. Please keep in mind that drafting a grand vision for the future is an explicit non-goal of this project, so what we need most are case studies and stakeholders. If this applies to you (and you can spare a little time), don’t hesitate to drop me a line.
