[ghc-steering-committee] GHC2023

[Joachim Breitner]

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 at joachim-breitner.de
  http://www.joachim-breitner.de/