Reduce AST & parser dependencies
In !5719 (closed), the number of parser dependencies edged up a bit, to the dissatisfaction of @shayne-fletcher-da. See https://blog.shaynefletcher.org/2020/10/ghc-lib-parser-module-count.html for more info. This ticket is about how to get the number of modules transitively depended on by the parser down.
I actually just tried to do it, but it's not so easy. Here is what I learned:
- SOURCE imports matter, because a SOURCE import still has to be in the same package as its importing module. Thus, if the parser depends on some low-level module that SOURCE-imports a high-level one, we're in for trouble.
- A key problem is that the parser transitively depends on
GHC.Driver.Env
, which brings inGHC.Driver.Hooks
and transitively odd things likeGHC.Cmm
. No no no. - It's hard to figure out exactly where this link happens, absent a visualization tool (which I did not try to set up).
- I found at least one way in, via
GHC.Hs.Expr
, which SOURCE-importsGHC.Tc.Types
, which importsGHC.Driver.Env
. So a good next step would be to not do this. - Of course, the parser has to depend on its AST, exported from
GHC.Hs.Expr
. But does it? It really only needs theGhcPs
variant of the AST. So I propose breakingGHC.Hs.Expr
intoGHC.Hs.Expr.Parser
,GHC.Hs.Expr.Rename
, andGHC.Hs.Expr.Tc
, each of which includes the definitions needed for its pass of the compiler. It seems likely we'd be able to getGHC.Hs.Expr.Parser
not to depend onGHC.Tc.Types
, and thus perhaps not onGHC.Driver.Env
. I have not tried this, at all, because it would be fairly major surgery, and it would make looking up type instances for e.g.XHsPar
harder. This seems like a promising way forward, however.
I'm moving on from this challenge now. This ticket is merely to serve as a small brain dump of what I accomplished. I pushed some (working) code to the wip/lower-parser-deps
branch, which anyone is free to take over. That commit successfully drops the dependency on GHC.Core.Lint
, and breaks up GHC.Cmm.Expr
in an attempt to kill the dependency on GHC.Cmm
. That last effort succeeded at breaking up GHC.Cmm.Expr
, but did not actually lose any dependency. (It actually picked up two new dependencies, because I created two new modules.) Perhaps picking up this branch is helpful, or perhaps not. I leave it to the next person to decide.