[ghc-steering-committee] Call for votes: Shall we have GHC2023

[Joachim Breitner]

Hi,

> GHC2021 turned out quite
> well, let's stick to it for a while and see how Haskell evolves in
> the next five to ten years.

that’s an interesting take. For me it was always clear that GHC20xx is
meant to be a continuous process (with yet to determined cadence), but
you are proposing that GHC2021 (not …xx!) could be, for now, the final
product? That’s certainly a valid position as well, but not one that
achieves the goals we (or at least I) had when coming up with the
GHC20xx.

Am Montag, dem 23.01.2023 um 02:20 +0300 schrieb Vladislav Zavialov:
> * We shouldn't change our mind about the recommended extensions so
> often

I don’t think it’s changing our mind. It’s a natural process of
stabilization and maturization that two years later some more
extensions have been proven to be good enough to no longer be
extensions, but simply be Haskell.

Also, we make mistakes. Over on the PR Oleg makes an excellent argument
why a language with Data.Safe.coerce and GeneralisedNewtypeDeriving
really also needs role annotations. I’d like to be able to fix my
mistakes.

> * We shouldn't overwhelm the user with unnecessary choice (which
> edition is best?)
>
> Right now it's down to Haskell98, Haskell2010, and GHC2021, which is
> good. Each added option makes things worse.

I disagree. Once we have, say, GHC2021, GHC2023 and GHC2024 out there.
Then these are not equally valid options, no more than programmers
currently decide whether to use text-0, text-1, or text-2. Like there,
our GHC20xx numbers are _versions_, and at least for new projects
hopefully nobody should ever have to pick an older version than the
newest supported by their GHC.

It is a good point, however, that we need to communicate that, and
present it in the users’s guide accordingly. For example, document the
latest prominently, and the others in a separate section “previous
language editions”. And maybe also document “on-by-default features
(default  since GHC20xx, can be disabled with -XNo…)” and actual
“extensions” separately.

(I agree that more options are bad, thus my motivation for GHC20xx is
to _reduce_ options that programmers have to make: by reducing the
number of language extensions they have to decide about!)

Cheers,
Joachim


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