A lot of alternative compilers have already be mentioned, like Hugs, uhc, nhc, Helium etc. But I want to mention one additional compiler: haskell-src-exts. Well, technically it isn’t a compiler, it is “only” a parser, but it was the foundation of a lot of great compiler-like Haskell tooling. We had renamers, mutation testing frameworks, source-to-source supercompilers, linters, refactoring tools etc. (The list of reverse dependencies of haskell-src-exts is here). One of the ideas was to have a suite of libraries that tooling can build on, the haskell-suite.
Among all this tooling that was developed, most became unmaintained, some, like hlint, invested the effort and switched to the ghc-lib-parser, but none of those still relying on haskell-src-exts work reliably on all of modern GHC-Haskell code.
In my opinion, we need a good replacement for the haskell-src-exts ecosystem more than we need another “Haskell source code to machine instructions” compiler. Nowadays it is already possible to use the ghc-lib-parser directly, but it is still much more inconvenient than what haskell-src-exts provided. Trying to write tooling which relies on any of the later AST representations, like renamed or typechecked Haskell code, by relying directly on the GHC Api, is both extremely difficult and also difficult to maintain.
If we dont have the necessary engineering power to maintain “just” another Haskell parsing library, I don’t see how another Haskell compiler which is sufficiently feature-rich to support modern Haskell libraries could be sustained.
But to end on a very optimistic note: I am looking with great enthusiasm at a lot of the effort that people are spending in making GHC more modular. Similarly, the splitting of cabal into separate libraries is making it easier to develop tooling for cabal files. I really liked David’s Haskell Symposium keynote about focusing on tooling in the next decade, and I think a more library-oriented approach to our compiling infrastructure is the way to get there.
