Charting a course toward a stable API for GHC

I don’t have time to continue work on GHC interface and architecture issues at the moment, unfortunately, but I would like to point out that some of the ideas from the paper ("Modularizing GHC" paper) and the proposal (Split out AST and Parser libraries from GHC by Ericson2314 · Pull Request #56 · haskellfoundation/tech-proposals · GitHub) are now implemented for Nix.

For example, see this file: nix/meson.build at master · NixOS/nix · GitHub Getting into the Meson details is out of scope, but suffice to say this is like a cabal.project file in that every subproject is like a Cabal package, and the overall things allows for a single incremental build (like the new multi-package REPL).

Nix, excluding testing, is 7 libraries, each of which is now its own package with its own configure script (analogous to me moving logic from the top-level configure script to the RTS configure script). Some of those libraries already existed, but some are new (for example libnixflakes was split out by me to isolate something more new controversial).

I anticipate doing more library splitting in the future, atop this foundation already built.

The build system rewrite and package split was done on-and-off over the past year.

I hope this example can help show that after-the-fact modularization and package-splitting of old widely-used code-bases is something that does actually happen — or at least some people elsewhere let me do it :D.

Over the past few years @romes has picked up the mantle from me working on TTG issues towards splitting out the AST and parser, which I am very grateful fo!. I really hope that the resumed effort can be fully aware of his efforts — or, better yet, fund him / fund others to work at his direction.

14 Likes