Modularizing GHC [pdf] | Hacker News Reader

Modularizing GHC [pdf]

hsyl20.fr

63 pointsEricson23148 comments

(That was the originally submitted URL but in this case I think it's probably best if the paper is linked above.)

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.

> 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/

> 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/ which I wasn't even aware of! But what really excites me is stuff like 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 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.

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.

GHC, too, compiles the surface language down to a series of progressively simpler intermediate languages. (See diagrams further into the paper.)

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-... 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!

Reply on news.ycombinator.com