> You can do a heart or lung transplant on GHC and make truly major changes and the type checker just guides you to do all the right things.
I thought GHC was famously a nightmare to work in?
> GHC is not exemplary of good large scale system design in a pure function language. Rather ironically, it violates the properties that draw people to functional programming in the first place: immutability, modularity, and composability
> many new features have been force-fitted into the existing code without proper redesign
> While the current design isn’t glorious, it works
I guess that's two different things. One person says "You can give GHC a heart transplant" and the other says "GHC needs a heart transplant: Here is our proposal". In fact, the very text you quote as saying GHC was famously a nightmare says:
> On the bright side, GHC is written in Haskell, and this language is particularly well suited to performing massive refactorings with confidence that nothing breaks. Thus, it should be possible to refactor the GHC library towards a more robust and versatile design
and in fact Simon Peyton Jones continued by saying exactly that:
> You can do a heart or lung transplant on GHC and make truly major changes and the type checker just guides you to do all the right things. The difficult stuff is envisioning and being very clear about what you’re trying to do. Actually doing it is often not that hard.
So the two texts and the two opinions are completely in alignment. GHC is famously bad insofar as it has a poor design. But once a better design is designed, you can give it the heart transplant it needs without excess stress.
I have no idea how the heart transplant proposed by Sylvain Henry, John Ericson and Jeffrey M. Young is going. I suppose at some point there should be something checked in and a report about how painful or painless it was (and, potentially, if it's really completely wrong, perhaps a series of bug reports in the next seven releases of GHC).
Almost all the recent work has been performed by Dominik Peteler (@mmhat) during Google summer of code, which John supervised. We've primarily been focused on landing !8341[0] which makes huge strides in Core w.r.t. modularity (see https://gitlab.haskell.org/ghc/ghc/-/issues/21872), but are on hold until schedules agree and some vacations end.
So the modularity project is far from dead. In fact Sylvain and I are planning on returning to it after we upstream the new Javascript backend (slated for 9.6, see MR!9133[1], tracking ticket[2]) hopefully this week.
PS: That patch is actually a good example of a gnarly lung transplant for GHC's Core IR (and done by a new contributor!).
I don't know. But - and this is my interpretation, not some summary of another talk - it sounds like Simon Peyton Jones, who is one of the people who are responsible for the poor state of the code, already answered that: "The difficult stuff is envisioning and being very clear about what you’re trying to do." Presumably, wherever his skills lie, they don't lie in envisioning a better state and refactoring the code towards that goal (to him, it was "difficult stuff", and left aside as he implemented changes that had a greater impact on its users). Afaik, for a long time GHC was maintained by the same two or three people so it probably shows the imprint of individual developers much more than your average compiler of similar size. Now development is much more open and this kind of technical debt is getting paid off.
I thought GHC was famously a nightmare to work in?
> GHC is not exemplary of good large scale system design in a pure function language. Rather ironically, it violates the properties that draw people to functional programming in the first place: immutability, modularity, and composability
> many new features have been force-fitted into the existing code without proper redesign
> While the current design isn’t glorious, it works
https://hsyl20.fr/home/files/papers/2022-ghc-modularity.pdf