# Single-compiler vs. multi-compilers (or. implementation-defined vs. standardized) languages

**URL:** <https://discourse.haskell.org/t/single-compiler-vs-multi-compilers-or-implementation-defined-vs-standardized-languages/5209>\
**Category:** Uncategorized\
**Created:** [October 23, 2022, 6:28am UTC](https://discourse.haskell.org/t/single-compiler-vs-multi-compilers-or-implementation-defined-vs-standardized-languages/5209 "2022-10-23T06:28:11Z")\
**Posts on this page:** 1\
**Showing post:** 16

<div class="post-metadata">

**Author:** ![hasufell](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/hasufell/32/1250_2.png) [@hasufell](https://discourse.haskell.org/u/hasufell)\
**Post date:** [October 26, 2022, 11:01am UTC](https://discourse.haskell.org/t/single-compiler-vs-multi-compilers-or-implementation-defined-vs-standardized-languages/5209/16 "2022-10-26T11:01:47Z")

</div>

Yes, but the reason an alternative on-par compiler doesn’t exist is not lack of resources.

I’m not sure SCB has a lot of interest in the new language features of GHC 9.x (at least I don’t as a Mu developer). Mu doesn’t even support all of 8.10.7 language extensions.

So if such a GHC 8.10.7 fork existed and was well and lively, maybe that would be a much more interesting base/target (maintaining patches, backends or depending on GHC API is much less work if the compiler is prioritizing stability… ask HLS devs).

That’s ofc my opinion.

---

_[View the full topic](https://discourse.haskell.org/t/single-compiler-vs-multi-compilers-or-implementation-defined-vs-standardized-languages/5209)._