From 81f0665513d65c2d7e544cbe8adeff4b0d6fdfff Mon Sep 17 00:00:00 2001 From: John Ericson Date: Sun, 10 Jan 2021 02:01:43 +0000 Subject: Separate AST from GhcPass (#18936) ---------------- What: There are two splits. The first spit is: - `Language.Haskell.Syntax.Extension` - `GHC.Hs.Extension` where the former now just contains helpers like `NoExtCon` and all the families, and the latter is everything having to do with `GhcPass`. The second split is: - `Language.Haskell.Syntax.` - `GHC.Hs.` Where the former contains all the data definitions, and the few helpers that don't use `GhcPass`, and the latter contains everything else. The second modules also reexport the former. ---------------- Why: See the issue for more details, but in short answer is we're trying to grasp at the modularity TTG is supposed to offer, after a long time of mainly just getting the safety benefits of more complete pattern matching on the AST. Now, we have an AST datatype which, without `GhcPass` is decently stripped of GHC-specific concerns. Whereas before, not was it GHC-specific, it was aware of all the GHC phases despite the parameterization, with the instances and parametric data structure side-by-side. For what it's worth there are also some smaller, imminent benefits: - The latter change also splits a strongly connected component in two, since none of the `Language.Haskell.Syntax.*` modules import the older ones. - A few TTG violations (Using GhcPass directly in the AST) in `Expr` are now more explicitly accounted for with new type families to provide the necessary indirection. ----------------- Future work: - I don't see why all the type families should live in `Language.Haskell.Syntax.Extension`. That seems anti-modular for little benefit. All the ones used just once can be moved next to the AST type they serve as an extension point for. - Decide what to do with the `Outputable` instances. Some of these are no orphans because they referred to `GhcPass`, and had to be moved. I think the types could be generalized so they don't refer to `GhcPass` and therefore can be moved back, but having gotten flak for increasing the size and complexity types when generalizing before, I did *not* want to do this. - We should triage the remaining contents of `GHC.Hs.`. The renaming helpers are somewhat odd for needing `GhcPass`. We might consider if they are a) in fact only needed by one phase b) can be generalized to be non-GhcPass-specific (e.g. take a callback rather than GADT-match with `IsPass`) and then they can live in `Language.Haskell.Syntax.`. For more details, see https://gitlab.haskell.org/ghc/ghc/-/wikis/implementing-trees-that-grow Bumps Haddock submodule --- compiler/ghc.cabal.in | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'compiler/ghc.cabal.in') diff --git a/compiler/ghc.cabal.in b/compiler/ghc.cabal.in index b7a68d8ba4..2264cb539b 100644 --- a/compiler/ghc.cabal.in +++ b/compiler/ghc.cabal.in @@ -714,6 +714,15 @@ Library GHC.Utils.Ppr GHC.Utils.Ppr.Colour + Language.Haskell.Syntax + Language.Haskell.Syntax.Binds + Language.Haskell.Syntax.Decls + Language.Haskell.Syntax.Expr + Language.Haskell.Syntax.Extension + Language.Haskell.Syntax.Lit + Language.Haskell.Syntax.Pat + Language.Haskell.Syntax.Type + reexported-modules: GHC.Platform.ArchOS , GHC.Platform.Host -- cgit v1.2.1