# Language, library, and compiler stability (moved from GHC 9.6 Migration guide)

**URL:** <https://discourse.haskell.org/t/language-library-and-compiler-stability-moved-from-ghc-9-6-migration-guide/5745>\
**Category:** Uncategorized\
**Created:** [February 4, 2023, 4:00pm UTC](https://discourse.haskell.org/t/language-library-and-compiler-stability-moved-from-ghc-9-6-migration-guide/5745 "2023-02-04T16:00:25Z")\
**Posts on this page:** 1\
**Showing post:** 83

<div class="post-metadata">

**Author:** ![angerman](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/angerman/32/892_2.png) [@angerman](https://discourse.haskell.org/u/angerman)\
**Post date:** [February 8, 2023, 4:31am UTC](https://discourse.haskell.org/t/language-library-and-compiler-stability-moved-from-ghc-9-6-migration-guide/5745/83 "2023-02-08T04:31:15Z")

</div>

Thank you for clarifying this @simonpj!

> [@simonpj](#):
>
> This is not theoretical. We have experienced extensive frustration with slow package updates. I am _not_ blaming the authors for that – there can be legitimate reasons. I just want a resiliency mechanism, that allows us to do extensive testing without relying on 100.0% timely responses from package authors: that’s head.hackage.

Why does this lead to “let’s patch the packages” instead of, “can we make the compiler more resilient to accept existing code”?

> [@simonpj](#):
>
> But again, you can only do so if the nightly build comes with packages that actually compile with it.

No, I could do that if the compiler accepted existing code (potentially with warnings), and not abruptly stops accepting existing code.

To come back to an earlier idea around a `-DEXPERIMENTAL` compiler, which could break arbitrarily and without any notice. Having a `experimental.hackage` overlay for this seems sensible to me.

---

_[View the full topic](https://discourse.haskell.org/t/language-library-and-compiler-stability-moved-from-ghc-9-6-migration-guide/5745)._