GHC20xx review; GHC2022 yes or no?

5 Oct 2021

      Hi Committee,

when we defined the process for GHC20xx, as written in 
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0372-gh...
we wrote

   Likely, the first iteration of this process will be vastly different
   from the following ones: The first one is expected to add a large
   number of uncontroversial extensions; so the next iteration will
   likely only make a smaller, but more controversial change.

   Therefore, this proposal does not commit to a fixed cadence.
   Instead, 6 months after the first release of a version of GHC that
   supports a GHC20xx set, we evaluate the outcome, the process, and
   the perceived need of a next release. At that time we will refine
   the processes, if needed, and set a cadence.

The first version of GHC that supported GHC20xx is 9.2, released in March.
So we should do this evaluation now.

My impression is that 9.2 hasn’t reached the masses yet:
NixOS stable doesn’t even have it, and the default is at 8.10. 
Stackage LTS is at 8.10, and nightly at 9.0
Debian is at 8.8.

So it seems premature to try to evaluate its impact, and what, if
anything, we should do differently for a hypothetical GHC2022.

So I suggest we postpone this review for another half year or so.

Also, I don’t see why GHC2022 would be different than GHC2021. Not that
much has changed about GHC and its set of “should-be-default”
extensions since last year, has it?

So I suggest we don’t work on defining GHC2022, and the next update
will be GHC2023 (or later).

What do you think,
Joachim 

-- 
Joachim Breitner
  mail@joachim-breitner.de
  http://www.joachim-breitner.de/

Joachim Breitner

Richard Eisenberg

Joachim Breitner

Simon Peyton Jones

Spiwack, Arnaud

Alejandro Serrano Mena

tags

participants (5)