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.
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'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.
8 comments
[ 2.9 ms ] story [ 32.4 ms ] thread(That was the originally submitted URL but in this case I think it's probably best if the paper is linked above.)
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.
Probably things are easier nowadays, with one-page guides like https://ghc.dev/
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 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.
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!