implementing-trees-that-grow.md

@@ -53,3 +53,98 @@ Here are some issues relating to that:
 - #19218
 
 ## Status
+
+The main work in recent months has been incrementally moving phase-specific stuff into extension points.
+This is trackeded in #16830.
+
+The larger picture has stayed, fairly constant, looking like:
+
+```haskel
+module GHC.Hs.Extension
+
+data NoExtField = ...
+data NoExtCon = ...
+
+data GhcPass = ...
+
+type family XConA p
+type family XConB p
+...
+```
+```haskell
+module GHC.Hs.Foo
+
+Data Foo p = ...
+
+type instance XConA GhcPs = ...
+type instance XConA GhcRn = ...
+type instance XConA GhcTc = ...
+
+...
+```
+
+This does mean that the AST and GHC stuff like `GhcPass` and it's instances is thoroughly mixed together.
+
+# Plan
+
+## #18936
+
+The next step per #18936 would be to change things up like this:
+
+```haskel
+module Language.Haskell.Syntax.Extension
+
+data NoExtField = ...
+data NoExtCon = ...
+
+type family XConA p
+type family XConB p
+...
+```
+```haskel
+module GHC.Hs.Extension.GhcPass
+
+data GhcPass = ...
+```
+```haskell
+module Language.Haskell.Syntax.Foo
+
+import Language.Haskell.Syntax.Extension
+
+Data Foo p = ...
+```
+```haskell
+module GHC.Hs.Foo
+
+import GHC.Hs.Extension.GhcPass
+import Language.Haskell.Syntax.Foo
+
+type instance XConA GhcPs = ...
+type instance XConA GhcRn = ...
+type instance XConA GhcTc = ...
+
+...
+```
+
+Now we hava a nice separation between the parts that ought to be GHC-specific and those that out to be GHC-agnostic.
+
+### Cleaving dependencies
+
+But, at firstt, the `Language.Haskell.Syntax` parts will still be tied to the rest of GHC in unfortunate ways, as the new dependencies test added in !4778 shows.
+
+ - Imports of the type checker: WIP fix in !4782
+
+ - `Outputable`. We could just move remaining instances to `Language.Haskell.Syntax.Foo`, but I have some fondness for making `Language.Haskell.Syntax.*.Ppr` modules in hopes that someday `Outputable` itself can become GHC-agnostic.
+
+ - `hs-boot` cycles. `Name`s, `Id`s, `Var`s, are somewhat jumbled.
+    Vars are mixed with Tc unification vars, and typed vars rerefernece `DataCon` and tons of other stuff via that.
+
+    Some of these specific issues here are to be solved elsewhere, e.g. #18758 / [design/type-refactor](design/type-refactor) about separating the Haskell and Core notions of a type.
+    But we need not be blocked on all that; we can just make more extension points, because even though the use of these types are not ntoday GHC-stage-specific, they certainly are GHC-specific.
+
+Or at least the beginning of it, more extension points might be needed for phase-agnostic but GHC-specific stuff.
+
+## #19218
+
+At long least, we move the `Language.Haskell.Syntax` modules to a separate package.
+We might want to make sure we have #10827 done by then so it's as easy to load the split GHC in GHCi as it is to load the original monolith.