4 ms·

Modularizing GHC [pdf]

63 points by Ericson2314 5y ago

dang 4y ago
Related blog post: https://hsyl20.fr/home/posts/2022-05-03-modularizing-ghc-paper.html https://hsyl20.fr/home/posts/2022-05-03-modularizing-ghc-pap.... (That was the originally submitted URL but in this case I think it's probably best if the paper is linked above.)
nh23423fefe 4y ago
I tried hacking on ghc years ago when it was still around 6.8. Everyone was helpful and friendly. But I just couldn't get any kind of dev env setup. Hopefully this work makes everything better for newbies, etc. I still love haskell and call it my favorite language to this day, even though I barely use it as much as I had before. It's just to pleasing to use.
- mhitza 4y ago
  > But I just couldn't get any kind of dev env setup Probably things are easier nowadays, with one-page guides like https://ghc.dev/ https://ghc.dev/
- Ericson2314 4y ago
  > Everyone was helpful and friendly. Yes the people are wonderful --- much nicer than the code! This is why it feels worth it to write something like this to try to steer such a big ship after so many years. > Hopefully this work makes everything better for newbies, etc. I certain hope so. The sibling comment linked https://ghc.dev/ https://ghc.dev/ which I wasn't even aware of! But what really excites me is stuff like https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5965 https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5965 Yes, you can just** `cabal build ghc` now (well, after a few quick other steps, also just does the compiler proper no std libs ;). I want to build on that with things like https://gitlab.haskell.org/ghc/ghc/-/issues/17191 https://gitlab.haskell.org/ghc/ghc/-/issues/17191 so all the complexity and bespoke nature of building GHC today just....goes away! While that is orthogonal to the types of non-modularity we discuss in this paper, it is very much a kindred project in spirit.
throwaway81523 4y ago
I'm partway through reading this. It is quite interesting. GHC has a standard disease of big old programs and refactoring the issues they describe will be a pretty impressive feat. I think doing something similar with GCC is likely hopeless. I wonder if GHC has to be so complicated, to compile the language that it compiles, including all the extensions. JHC was a lot smaller but internally used a dependently typed intermediate language, that simplified some things. Of course it didn't implement nearly as complicated a language as GHC does.
- simonmic 4y ago
  GHC, too, compiles the surface language down to a series of progressively simpler intermediate languages. (See diagrams further into the paper.)
- Ericson2314 4y ago
  Yes indeed, the problems are hardly GHC-specific, being common in much old software. I'm a big believer in the classic https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i https://www.joelonsoftware.com/2000/04/06/things-you-should-... such that I much rather refactor GHC even if starting over, or working on Idris 2, is tempting. > I think doing something similar with GCC is likely hopeless. I think it could be done, but yes refactoring Haskell is so much easier — an opportunity to be embraced!
simonmic 4y ago
Related discussion: https://www.reddit.com/r/haskell/comments/uhdu4l/modularizing_ghc_paper/ https://www.reddit.com/r/haskell/comments/uhdu4l/modularizin...

63 points by Ericson2314 5y ago

dang 4y ago

Related blog post: https://hsyl20.fr/home/posts/2022-05-03-modularizing-ghc-paper.html https://hsyl20.fr/home/posts/2022-05-03-modularizing-ghc-pap.... (That was the originally submitted URL but in this case I think it's probably best if the paper is linked above.)

nh23423fefe 4y ago

I tried hacking on ghc years ago when it was still around 6.8. Everyone was helpful and friendly. But I just couldn't get any kind of dev env setup. Hopefully this work makes everything better for newbies, etc. I still love haskell and call it my favorite language to this day, even though I barely use it as much as I had before. It's just to pleasing to use.

mhitza 4y ago
> But I just couldn't get any kind of dev env setup Probably things are easier nowadays, with one-page guides like https://ghc.dev/ https://ghc.dev/
Ericson2314 4y ago
> Everyone was helpful and friendly. Yes the people are wonderful --- much nicer than the code! This is why it feels worth it to write something like this to try to steer such a big ship after so many years. > Hopefully this work makes everything better for newbies, etc. I certain hope so. The sibling comment linked https://ghc.dev/ https://ghc.dev/ which I wasn't even aware of! But what really excites me is stuff like https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5965 https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5965 Yes, you can just** `cabal build ghc` now (well, after a few quick other steps, also just does the compiler proper no std libs ;). I want to build on that with things like https://gitlab.haskell.org/ghc/ghc/-/issues/17191 https://gitlab.haskell.org/ghc/ghc/-/issues/17191 so all the complexity and bespoke nature of building GHC today just....goes away! While that is orthogonal to the types of non-modularity we discuss in this paper, it is very much a kindred project in spirit.

throwaway81523 4y ago

I'm partway through reading this. It is quite interesting. GHC has a standard disease of big old programs and refactoring the issues they describe will be a pretty impressive feat. I think doing something similar with GCC is likely hopeless. I wonder if GHC has to be so complicated, to compile the language that it compiles, including all the extensions. JHC was a lot smaller but internally used a dependently typed intermediate language, that simplified some things. Of course it didn't implement nearly as complicated a language as GHC does.

simonmic 4y ago
GHC, too, compiles the surface language down to a series of progressively simpler intermediate languages. (See diagrams further into the paper.)
Ericson2314 4y ago
Yes indeed, the problems are hardly GHC-specific, being common in much old software. I'm a big believer in the classic https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i https://www.joelonsoftware.com/2000/04/06/things-you-should-... such that I much rather refactor GHC even if starting over, or working on Idris 2, is tempting. > I think doing something similar with GCC is likely hopeless. I think it could be done, but yes refactoring Haskell is so much easier — an opportunity to be embraced!

simonmic 4y ago

Related discussion: https://www.reddit.com/r/haskell/comments/uhdu4l/modularizing_ghc_paper/ https://www.reddit.com/r/haskell/comments/uhdu4l/modularizin...