Hierarchical Module Structure for GHC
The aim is to introduce a module hierarchy for GHC. Currently GHC modules don't even have a "GHC." prefix.
- cleaner code base and overall code structure easier to grasp (no more short cryptic module names)
- better integration with other packages when using GHC API
- better haddocks documentation
- break the GHC (plugin) API
- may make "rebase" harder during the transition period
- proposal by Nominolo https://ghc.haskell.org/trac/ghc/wiki/ModuleDependencies/Hierarchical
- I (@hsyl20) don't know what happened to it.
- June: attempt to revive the 2008 proposal by @hsyl20. A fresher renaming has been proposed along with a BIG patch discussed on Phabricator: https://phabricator.haskell.org/D3647.
- writing a GHC proposal about this change has been suggested. It has been written and discussed here: https://github.com/ghc-proposals/ghc-proposals/pull/57
- implementing a compatibility package exporting module old names has been suggested and implemented: https://github.com/hsyl20/ghc-api-compat/blob/master/ghc-api-compat.cabal
- October: the proposal has been flagged as out-of-scope, I've lost the motivation to rebase the big patch.
- no single big patch: smaller patches, one at a time to avoid tiresome rebasing.
- not too much renaming. Mostly replacing prefixes (e.g. StgCmmFoo becomes GHC.StgToCmm.Foo)
- Wiki page describing the proposal:
- IR-to-IR modules:
- GHC.Builtin: primops, etc.
- GHC.Config: Constants, DynFlags, etc.
- GHC.Platform: platform specific stuff (register mapping, word-size, etc.)
- GHC.Data: data structures (Bag, Graph, FiniteMap, EnumSet, etc.)
- GHC.BasicTypes: Name, Module, OccName, NameEnv, NameCache...
- GHC.Driver: pipeline driver (Backpack, Finder, Main, Make, MakeDepend, etc.)
- GHC.Interactive: interactive evaluation stuff (Debugger, Eval, etc.)
- GHC.Plugin: plugins
- GHC.Util: SysTools, IO stuff, etc.