Hi, Am Freitag, dem 04.11.2022 um 17:10 +0000 schrieb Simon Marlow:
Having said that, at work we've been using our own version of GHC2021 for many years now (by just enabling a set of extensions by default in the build system) and I'm often reminded how much time it saves.
I'm somewhat persuaded by the people on the discourse thread arguing that if the point is stability, then we should not produce new iterations too frequently. But what is too frequent?
I’d say the point is not stability. Or, at least not what some people might expect from stability… The point of the GHC20xx series is to get (proven, useful, uncontroversial) goodies into the hands of our users _by default_. Because GHC is actively developed, the set of proven useful uncontroversial goods of course changes, so expecting stability from “the latest GHC20xx” is contradictory! And there are plenty of use cases where such stability isn’t needed. The one-shot script or GHCi session foremost. But also as an application developer, I may target one fixed GHC version anyways, and am happy to have the language evolve (in usually non-disruptive ways anyways) whenever I upgrade the GHC version I am using. And those who need more stability (e.g. library authors publishing code that needs to work with multiple GHC versions) are likely to pin their default-language anyways, e.g. to GHC2021. And _that_ is stable! So I think we can define frequent (yearly or twoyearly or whatever makes sense organically) without compromising those who want stability. And (as I mentioned elsewhere already), there is an inherent long delay between defining GHC20xx and large-scale adoption. I don’t think that’s a reason to reduce the frequency. If GHC2021 lacks some useful extension (say, -XDeriveAnotherClass), then we likely want that to be available as soon as possible. Waiting for GHC2025 just means it’s even two more years (in addition to the delay) before it reaches our users. TL;DR: I see nothing wrong with and advocate for defining relatively frequent and possible small incremental GHC20xx editions. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/