<div dir="ltr"><div><div><div>Hi,</div><div><br></div><div>I just wanted to add a few things from a perspective of a GHC newbie. Not</div><div>everything is a concrete proposal on how to improve things, but I hope it's</div><div>still useful.</div><div><br></div><div>First of all, a big +1 on what Moritz said - having everything in one system</div><div>like Phab would be really nice.</div><div><br></div><div>But I also want to second what Richard Fung said in another thread - the biggest</div><div>barrier for involvement for me is understanding the code (i.e., it’s a complex</div><div>and large project).</div><div><br></div><div>Yes, Phab/Trac are an additional hassle, but for me not really that significant</div><div>compared to the task of understanding what’s happening in the compiler (although</div><div>small, localized contributions might be an exception here!).</div><div><br></div><div>So let's start with the things that I personally find helpful :-)</div><div><br></div><div>- Some of the documentation on Trac is great (e.g., "I know kung fu: learning</div><div>  STG by example" [1] is amazing!)</div><div><br></div><div>- “Notes” in the code (especially the ones that give concrete examples of how we</div><div>  want to transform the code and why!) are super useful.</div><div><br></div><div>- Modify & compile cycle is super quick when using `make 1` or `make 2` in</div><div>  `compiler/`.</div><div><br></div><div>- Ability to use `Outputable` instances with `Debug.Trace.trace` works</div><div>  surprisingly well. (Although mapping the output from `Outputable` back to AST</div><div>  can be non-trivial!)</div><div><br></div><div>Things that I find problematic:</div><div><br></div><div>- Some of the documentation on Trac is outdated or appears to be a "work in</div><div>  progress" but hasn't been updated in years.  So getting a clear idea of what’s</div><div>  the current status, is not always easy.  Also, it's not always easy to find...</div><div>  Maybe documentation on the wiki could follow the directory/module structure</div><div>  more closely? (also making it more obvious when it gets out of date)</div><div><br></div><div>- There's a lot of knowledge that seems to be assumed from the reader. I'm</div><div>  guessing that most of the key concepts are obvious for regular contributors.</div><div>  But this can be quite challenging for newcomers and unfortunately explanations</div><div>  can be spread around across code, papers, etc. (e.g., it took me a while to</div><div>  understand what's the deal with "join-points" and "let-no-escape").</div><div>  Not sure how to solve this, except for having better documentation...</div><div><br></div><div>- Validate often fails. Workaround: run `./validate` without a patch and then</div><div>  with the patch. If there are no differences, it's probably unrelated.</div><div>  It'd be much nicer if this wasn't necessary.</div><div><br></div><div>- Coding style. I personally do find it quite distracting to jump between</div><div>  modules that are using a different style (often wildly different!). It</div><div>  definitely does slow me down.</div><div>  And bad formatting can be actually pretty harmful, e.g., not that long ago,</div><div>  I wasted half an hour just because of a weird formatting of a do-block! [3]</div><div>  Finally, note that coding style is pretty much a standard today, so many</div><div>  people expect it in well maintained codebases and might see the current state</div><div>  as "messy".  (And perceptions do matter sometimes!)</div><div>  The solution here would be to adopt an official coding style (e.g., [2]).</div><div><br></div><div>Anyway, I hope you find this useful. :-)</div><div><br></div><div>Cheers,</div><div>Michal</div><div><br></div><div><br></div><div>[1] <a href="https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/GeneratedCode">https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/GeneratedCode</a></div><div><br></div><div>[2] <a href="https://github.com/tibbe/haskell-style-guide">https://github.com/tibbe/haskell-style-guide</a></div><div><br></div><div>[3] I was looking at a do-block like this:</div><div><br></div><div>do { A</div><div>   ; …</div><div>   …</div><div>   …</div><div>   …</div><div>   ; B</div><div>   }</div><div><br></div><div>where it seems that both A and B should always execute. Except that, after</div><div>closer examination, there were two blocks present!</div><div><br></div><div>do { A</div><div>   ; …</div><div>   …</div><div>     foobar $ \x -> do</div><div>   …</div><div>   ; B</div><div>   }</div><div><br></div><div>They were just indented to make it appear as if there was just one! :-(</div></div></div><div><br></div></div>