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

[angerman]

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.