Hi GHC devs, With John Ericson and Jeffrey Young we wrote a paper about the modularization of GHC. It gives a global picture for the refactorings we have been performing (c.f. e.g. #17957) and some potential future ones. Announce blog post: https://hsyl20.fr/home/posts/2022-05-03-modularizing-ghc-paper.html Paper: https://hsyl20.fr/home/files/papers/2022-ghc-modularity.pdf Discussion on Reddit: https://www.reddit.com/r/haskell/comments/uhdu4l/modularizing_ghc_paper/ We welcome any feedback, here or on reddit. Cheers, Sylvain
I am very happy to see this paper. It was an enjoyable read, and accessible
to non-experts such as myself. I appreciated the effort spent on research,
and was even happier to see that you have started implementing these
suggestions and have a plan going forward. Technical debt is a hard thing
to overcome, especially in the face of a rapidly evolving language.
This paper resonates with me as both a user and one-time (as in a single
time🙂) developer of GHC. As a user, I’ve run into issues related to the
debts you discuss. I also tried to fix a GHC bug, and remember being
overwhelmed by DynFlags.
I applaud your efforts. Thank you for this service to the Haskell community.
Eric Crockett
On Wed, May 4, 2022 at 3:51 AM Sylvain Henry
Hi GHC devs,
With John Ericson and Jeffrey Young we wrote a paper about the modularization of GHC. It gives a global picture for the refactorings we have been performing (c.f. e.g. #17957) and some potential future ones.
Announce blog post: https://hsyl20.fr/home/posts/2022-05-03-modularizing-ghc-paper.html Paper: https://hsyl20.fr/home/files/papers/2022-ghc-modularity.pdf Discussion on Reddit: https://www.reddit.com/r/haskell/comments/uhdu4l/modularizing_ghc_paper/
We welcome any feedback, here or on reddit.
Cheers, Sylvain
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
This is a great paper! The explanation of how DynFlags has wormed its way into more and more functions is quite interesting. I wonder if, in general, some developers lean away from refactoring and more towards "getting things done", whereas other developers lean into code refactoring and decreasing technical debt. A few comments: On page 2, the first sentence about design patterns derived from OO literature seems a little awkward. On page 7, the phrase "code smell" could maybe be replaced. In my experience the phrase "code smell" is often used to avoid explaining why an anti-pattern is actually problematic. It is also a neologism, and is only used once in the paper. On page 30, the explanation of DDD talks about "business rules", "business knowledge", "business software", "business situation", "business code", etc. was unfamiliar to me. It seems to use the word "business" to talk about the specific goal of the code. This seems to be using language specific to corporations to talk about the . The usage of "business" in this way is limited to pages 30, 31, and 34. On page 34, I didn't find the relationship between Figure 1 and Figure 2 entirely clear. It sounds like Figure 1 is the way things are, and Figure 2 is the way that things should be? Maybe that could be made clearer in the figure captions. Also, it seems like the main difference in the figures is that Figure 2 replaces mutual dependency between the boxes on the right (i.e. "Type checker, renamer") and the output languages ("Haskell", "Core") with mutual dependencies between the output languages... is that good, and if so, why? On page 37, its unclear to me what A and B are. Other than that, I found the paper really easy to read! I personally found the purpose of disentangling different parts of the compiler intuitively clear -- modularity and separation of concerns seem like an obvious goal. The quoted text on the topic of "supple design" seems very motivating! -BenRI On 5/4/22 6:42 AM, Sylvain Henry wrote:
Hi GHC devs,
With John Ericson and Jeffrey Young we wrote a paper about the modularization of GHC. It gives a global picture for the refactorings we have been performing (c.f. e.g. #17957) and some potential future ones.
Announce blog post: https://hsyl20.fr/home/posts/2022-05-03-modularizing-ghc-paper.html Paper: https://hsyl20.fr/home/files/papers/2022-ghc-modularity.pdf Discussion on Reddit: https://www.reddit.com/r/haskell/comments/uhdu4l/modularizing_ghc_paper/
We welcome any feedback, here or on reddit.
Cheers, Sylvain
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
re: page 30, the term "business" should really be understood as the core thing that the code has to achieve. It's not the supporting infrastructure but rather the reason of being of the code. No actual relation with a company. Even non-corporate codebases have business logic and supporting / infrastructural code. And I'd like to join you in praising the paper, it is really a nice piece of literature that makes me want to support GHC development even more! Le 04/05/2022 à 20:12, Benjamin Redelings a écrit :
This is a great paper! The explanation of how DynFlags has wormed its way into more and more functions is quite interesting. I wonder if, in general, some developers lean away from refactoring and more towards "getting things done", whereas other developers lean into code refactoring and decreasing technical debt.
A few comments:
On page 2, the first sentence about design patterns derived from OO literature seems a little awkward.
On page 7, the phrase "code smell" could maybe be replaced. In my experience the phrase "code smell" is often used to avoid explaining why an anti-pattern is actually problematic. It is also a neologism, and is only used once in the paper.
On page 30, the explanation of DDD talks about "business rules", "business knowledge", "business software", "business situation", "business code", etc. was unfamiliar to me. It seems to use the word "business" to talk about the specific goal of the code. This seems to be using language specific to corporations to talk about the . The usage of "business" in this way is limited to pages 30, 31, and 34.
On page 34, I didn't find the relationship between Figure 1 and Figure 2 entirely clear. It sounds like Figure 1 is the way things are, and Figure 2 is the way that things should be? Maybe that could be made clearer in the figure captions. Also, it seems like the main difference in the figures is that Figure 2 replaces mutual dependency between the boxes on the right (i.e. "Type checker, renamer") and the output languages ("Haskell", "Core") with mutual dependencies between the output languages... is that good, and if so, why?
On page 37, its unclear to me what A and B are.
Other than that, I found the paper really easy to read! I personally found the purpose of disentangling different parts of the compiler intuitively clear -- modularity and separation of concerns seem like an obvious goal. The quoted text on the topic of "supple design" seems very motivating!
-BenRI
On 5/4/22 6:42 AM, Sylvain Henry wrote:
Hi GHC devs,
With John Ericson and Jeffrey Young we wrote a paper about the modularization of GHC. It gives a global picture for the refactorings we have been performing (c.f. e.g. #17957) and some potential future ones.
Announce blog post: https://hsyl20.fr/home/posts/2022-05-03-modularizing-ghc-paper.html Paper: https://hsyl20.fr/home/files/papers/2022-ghc-modularity.pdf Discussion on Reddit: https://www.reddit.com/r/haskell/comments/uhdu4l/modularizing_ghc_paper/
We welcome any feedback, here or on reddit.
Cheers, Sylvain
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD
participants (4)
-
Benjamin Redelings -
Eric Crockett -
Hécate -
Sylvain Henry