[ghc-steering-committee] GHC2023

[Joachim Breitner]

Hi Committee,

when we defined the process for GHC20xx, as written in 
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0372-ghc-extensions.rst
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 GHC2021 was 9.2, released in
October 2022.

Last fall we said that not enough time has passed to do such an
evaluation, and we skipped defining GHC2022.

Another year has passed, and if we are serious with the idea that
GHC20xx is a continuous thing, we should probably start defining
GHC2023 – even if it is just a small delta. This e-mail tries to
kickstart that process.


Last time we did a relative elaborate thing where we voted on
essentially _every_ extension. I think that made sense for the first
iteration, where we had to winddow down the likely extensions. But now
we have a base line (GHC2021), and are asked to find a suitable delta,
and I’d go for a nomination-based approach: Committee members can
propose adding (or removing, in theory) specific extensions, and then
we vote only on those. Does that sound reasonable?

Does anyone have any insight from the real world? Has GHC2021 helped
our users? And if not, why not?

What kind of hard data would you like to see, if any?

(I’m a bit wary of spending too much time writing scripts to scrape
hackage, for example to see which extensions people tend to enable _in
addition_ to GHC2021, only to see that libraries on hackage are
understandably slow to use default-language: GHC2021, as that’s not
great for backward compat for now. But I am also not sure where to look
for good data…)

Cheers,
Joachim

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