Create 2023-09-15.md

Author: david-christiansen

meetings/2023-09-15.md

@@ -0,0 +1,91 @@
+# TWG 2023-09-15
+
+[Prior notes](https://github.com/haskellfoundation/tech-proposals/blob/main/meetings/2023-08-11.md)
+
+## Present
+
+ * Hécate
+ * John
+ * Noon
+ * Laurent
+ * Jack
+ * David
+
+## Goodbye from David
+
+ - Open issues to be resolved?
+ - Status of committee during transition?
+    - Meetings will continue between EDs. David will email board and invite them to select a representative to attend; funding requests will be sent to Richard
+    - Laurent is volunteer secretary - will create notes document
+
+## Module naming convention proposal
+https://github.com/haskellfoundation/tech-proposals/pull/53
+
+ - Unanimously approved
+
+## Parser proposal
+https://github.com/haskellfoundation/tech-proposals/pull/56
+
+ * John: main motivation is a general commitment to modularity. But not everyone shares these values, and the proposal needs an argument for these  people! Today, the most common way to parse Haskell code is `ghc-lib`, which is a giant kludge and hard to maintain. It woudl be nice to fix this. Today, it's also mostly impossible to depend on a newer GHC API to write a tool that can be built on older ones.
+     * Richard was convinced on the thread, confirmed this in personal conversation
+     * Simon less convinced thus far, but discussions are ongoing
+ * Laurent: Name is on proposal, but John did the work. Initially supported this because he wanted to use it for the Haddock refactor. But many people want to use other parts of GHC - e.g. name resolution - and these will still need to depend on GHC. As the proposal is written right now, it wouldn't solve this or a number of other projects. Has no input as to whether it will help other projects - not a user of hlint, let alone an expert.
+ * John: Either this is not enough or it's overkill. The ghc-lib parser is used by hlint and other tools, not the rest of GHC, so there is something to use there. The ghc-lib parser has more modules than we'd like (e.g. C-- is included - see https://hackage.haskell.org/package/ghc-lib-parser). But we think we can reduce this without throwing the baby out with the bathwater. We do have some prior art other than Haddock. 
+ * Noon: Reading the proposal - money is needed to finish Trees that Grow. Who would do it and what would it cost?
+ * John: There's a time estimate to do the splitting of the AST, but no time estimate for the parser part because it's still buried behind the AST part. Assumed it could be done in two separately funded stages, with the AST as a trial run.
+ * Noon: You do eventually want to fund the whole thing, right?
+ * John: Integration work woudl be volunteer, Shane volunteered for hlint and Laurent would do so with Haddock if the lib were sufficient.
+ * David: Is there a use case for an AST without a parser?
+ * John: That was the HAddock case - GHC would emit the AST in hi-haddock.
+ * David: Since it seems that Haddock may not work, can we do anything else instead?
+ * John: No
+ * David: What about TH and compiler plugins?
+ * John: Plugins likely need the GHC extension points, but TH might be a good one. It was in the paper, but it seems to be too much of a long-term one. Lots of differences between TH AST and GHC.
+ * Jack: Was wondering - C-- was in Haddock for a weird reason. Why?
+ * John: It was ghc-lib-parser. Shane has a test library that uses the libraries he needs, then he has as script that grabs the import closure of modules that he uses. There's some transitive dependency on C-- that results in its inclusion.
+ * David: Remaining stakeholders - developers of Ormolu and Fourmolu.
+ * John - agrees
+ * David: What is Simon's concern, spoken in person?
+ * John: He expressed that having a separation between libraries inside GHC 
+ * David suspects these concrete things:
+    - More recompiling
+    - Harder to navigate the codebase
+    - Observing workflow, do a taylorism
+    - Version bounds?
+      - Should be released in lockstep. (John's intent all along, but might not be in the proposal against)
+      - Can mention PvP vs lockstop tradeoff
+ * What's next
+    - Get feedback in the thread
+    - Other authors
+    - Simon, Ben, Alan, Chris Done
+    - Address Simon's points in https://github.com/haskellfoundation/tech-proposals/pull/56#issuecomment-1698713212
+       - No disagreeement on the source spans being part of the parser
+       - Thoughts on scope
+ * Hecate also looking to the future
+    - Want more tools
+    - Give a little boost to "stable GHC API stuff" (e.g. thinking about stable parser interface in isolation)
+ * Hecate has two others:
+     * `refact` / `apply-refact` 
+       - John would like to better understand the divsion of labor between these two things
+     * FB's  Haskell rewrite rule project `retrie` (https://github.com/facebookincubator/retrie)
+ * Why not just use GHC directly?
+    - Ask creators of these tools
+    - Rebuild times
+    - Reinstallability
+ * John will start with involving more tool author stakeholders
+ * Add Formulu
+ * Noon: If this is really our first funding, then we need more detail on how much it would cost.
+ * John: We really need the parser to deliver value, and it's just really, really hard to figure out what that will cost.
+ * Noon: To clarify - the question is how much to pay a consultant
+ * John: That's right - the cost of the parser is totally unknown - low-information estimate is twice as much as the AST, but this is a big unknown.
+ * David: Is there some small thing we can do to get more info?
+ * John: Analyzing the import graph is one way
+
+## Other Business
+ - Close other proposals for inactivity?
+   - Yes
+ - Recruiting at ICFP?
+   - Gershom not here, ask him next time  
+   - New ED will be responsible for recruiting
+ - Sysadmin help?
+   - Waiting for Davean