Call for votes: Shall we have GHC2023

Joachim Breitner

22 Jan 2023 22 Jan '23

7:40 a.m.

Hi Committee, as ~threatened~ announced, I’m calling for a vote on whether we should proceed to define the next GHC20xx _now_, as GHC2023, or wait for a year. Judging from the silence around the PR for GHC2023 I deduce that the appetite for GHC2023 is generally low, and will not bother you with complicated looking questions about which extensions might make GHC2023 worth it in an attempt to parallelize the “whether” with the “what”. Instead, please cast your vote until Apri 5 (but preferrably earlier) on the question: Should we proceed towards GHC2023? (If yay wins we’ll refine #559 and vote on that. If nay wins, I’ll stay quiet until next fall.) I am intentionally not asking for a fixed cadence at this point. We have made but one release so far, and it seems presumptious to try to predict what makes most sense next year, or the next four years to come. (I’ll follow up with my vote and justification separately.) Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Show replies by date

Joachim Breitner

22 Jan 22 Jan

7:57 a.m.

Hi, unsurprisingly, I vote Am Sonntag, dem 22.01.2023 um 13:40 +0100 schrieb Joachim Breitner:

...

Should we proceed towards GHC2023?

Yes! Brief summary of why: * One goal of GHC20xx was to fix one problem we had with the Haskell20xx process: New releases were rare, small and eventually stopped. So I want GHC20xx to not fall in the same trap of being over-cautious when making releases. * A early and small(!) (e.g. just adding role annotations) release gives both us and the community a chance to practice. It is a good way to learn that new GHC20xx releases are _not_ a big deal, and those users who upgrade will learn that upgrading is (well, can be) totally painless. I’d like to let them have such a positive experience. * Assuming that every GHC20xx is “better” in some sense than the previous, and even if it is just mild QoL improvements, I see little gain in holding that back longer than necessary. * GHC20xx releases are lower pain than GHC releases or base changes! A new version of GHC you _have_ to upgrade to get important fixes. A new version of base you _have_ to upgrade to, else you cannot get new versions of your dependencies. These upgrades are forced on the user, with only limited wiggle room. A new GHC20xx is totally optional. Your -XGHC2021 code will just continue to work as you upgrade GHC. So if it is _less_ disruptive, why have a longer cadence? Or, as a friend of mine nicely put it: Even if there are users out there that are best served by having GHC2021, GHC2024, GHC2027…, they are free and welcome to only bump their edition every three years. Also having GHC2023 and GHC2025 … does not in any way impact them. So because of their opt-in, usually-pinned nature, backward compat worries need not restrict us here, I’d say. Hence I’d like to define a GHC2023 (in time for GHC 9.8?). And I wouldn’t worry about a _fixed_ cadence until we had two or three releases and learned from it. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Chris Dornan

8:11 a.m.

I agree that we should release GHC2023 for all the reason Joachim says. Each GHCXXXX release is just our declaration of the extensions that we think should be enabled by default. It is going to change as we larn more about the extensions, let's clean as we go and make an annual statement of our recommended Haskell brew. If we are not prepared to spend a bit of time thinking about whether we recommend extensions we have already defined then that, to me, suggests something is off. What do you say Joachim to publishing schedule for proposing additions (and deletions) and then voting on them. I was think we could take the year but having a 9.8-friendly schedule makes sense. Anyway my vote is for yes to GHC2023. Chris

...

On 2023-01-22, at 12:57, Joachim Breitner wrote:

Hi,

unsurprisingly, I vote

Am Sonntag, dem 22.01.2023 um 13:40 +0100 schrieb Joachim Breitner:

...
Should we proceed towards GHC2023?

Yes!

Brief summary of why:

* One goal of GHC20xx was to fix one problem we had with the Haskell20xx process: New releases were rare, small and eventually stopped. So I want GHC20xx to not fall in the same trap of being over-cautious when making releases.

* A early and small(!) (e.g. just adding role annotations) release gives both us and the community a chance to practice. It is a good way to learn that new GHC20xx releases are _not_ a big deal, and those users who upgrade will learn that upgrading is (well, can be) totally painless. I’d like to let them have such a positive experience.

* Assuming that every GHC20xx is “better” in some sense than the previous, and even if it is just mild QoL improvements, I see little gain in holding that back longer than necessary.

* GHC20xx releases are lower pain than GHC releases or base changes!

A new version of GHC you _have_ to upgrade to get important fixes. A new version of base you _have_ to upgrade to, else you cannot get new versions of your dependencies. These upgrades are forced on the user, with only limited wiggle room.

A new GHC20xx is totally optional. Your -XGHC2021 code will just continue to work as you upgrade GHC. So if it is _less_ disruptive, why have a longer cadence?

Or, as a friend of mine nicely put it: Even if there are users out there that are best served by having GHC2021, GHC2024, GHC2027…, they are free and welcome to only bump their edition every three years. Also having GHC2023 and GHC2025 … does not in any way impact them.

So because of their opt-in, usually-pinned nature, backward compat worries need not restrict us here, I’d say.

Hence I’d like to define a GHC2023 (in time for GHC 9.8?). And I wouldn’t worry about a _fixed_ cadence until we had two or three releases and learned from it.

Cheers, Joachim

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

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Vladislav Zavialov

6:20 p.m.

I vote against frequent language editions for two reasons: * We shouldn't change our mind about the recommended extensions so often * 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. 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. - Vlad On Sun, Jan 22, 2023 at 4:11 PM Chris Dornan wrote:

...

I agree that we should release GHC2023 for all the reason Joachim says. Each GHCXXXX release is just our declaration of the extensions that we think should be enabled by default. It is going to change as we larn more about the extensions, let's clean as we go and make an annual statement of our recommended Haskell brew. If we are not prepared to spend a bit of time thinking about whether we recommend extensions we have already defined then that, to me, suggests something is off.

What do you say Joachim to publishing schedule for proposing additions (and deletions) and then voting on them. I was think we could take the year but having a 9.8-friendly schedule makes sense.

Anyway my vote is for yes to GHC2023.

Chris

Joachim Breitner

23 Jan 23 Jan

2:42 a.m.

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

Arnaud Spiwack

3:22 a.m.

...

Should we proceed towards GHC2023?

I don't feel very strongly either way. Am I allowed to be a pain and vote “weak wait”? That'd be my inclination.

Simon Peyton Jones

3:36 a.m.

I vote we wait until at least 2024. Simon On Sun, 22 Jan 2023 at 12:40, Joachim Breitner wrote:

...

Hi Committee,

as ~threatened~ announced, I’m calling for a vote on whether we should proceed to define the next GHC20xx _now_, as GHC2023, or wait for a year.

Judging from the silence around the PR for GHC2023 I deduce that the appetite for GHC2023 is generally low, and will not bother you with complicated looking questions about which extensions might make GHC2023 worth it in an attempt to parallelize the “whether” with the “what”.

Instead, please cast your vote until Apri 5 (but preferrably earlier) on the question:

Should we proceed towards GHC2023?

(If yay wins we’ll refine #559 and vote on that. If nay wins, I’ll stay quiet until next fall.)

I am intentionally not asking for a fixed cadence at this point. We have made but one release so far, and it seems presumptious to try to predict what makes most sense next year, or the next four years to come.

(I’ll follow up with my vote and justification separately.)

Cheers, Joachim

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

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Adam Gundry

3:38 p.m.

I vote we proceed with GHC2023. There are inconsistencies in GHC2021 that would be better to sort out sooner rather than later (e.g. the fact that GADTs snuck in through the back door, with GADTSyntax and ExistentialQuantification both included but neither GADTs nor MonoLocalBinds). That's entirely understandable, given that it was a first attempt at something new, but I don't see why we shouldn't make some small improvements in the next iteration. Adam On 23/01/2023 08:36, Simon Peyton Jones wrote:

...

I vote we wait until at least 2024.

Simon

On Sun, 22 Jan 2023 at 12:40, Joachim Breitner mailto:mail@joachim-breitner.de> wrote:

Hi Committee,

as ~threatened~ announced, I’m calling for a vote on whether we should proceed to define the next GHC20xx _now_, as GHC2023, or wait for a year.

Judging from the silence around the PR for GHC2023 I deduce that the appetite for GHC2023 is generally low, and will not bother you with complicated looking questions about which extensions might make GHC2023 worth it in an attempt to parallelize the “whether” with the “what”.

Instead, please cast your vote until Apri 5 (but preferrably earlier) on the question:

Should we proceed towards GHC2023?

(If yay wins we’ll refine #559 and vote on that. If nay wins, I’ll stay quiet until next fall.)

I am intentionally not asking for a fixed cadence at this point. We have made but one release so far, and it seems presumptious to try to predict what makes most sense next year, or the next four years to come.

(I’ll follow up with my vote and justification separately.)

Cheers, Joachim

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England

Joachim Breitner

5 Feb 5 Feb

11:22 a.m.

Hi, Am Sonntag, dem 22.01.2023 um 13:40 +0100 schrieb Joachim Breitner:

...

Instead, please cast your vote until Apri 5 (but preferrably earlier) on the question:

Should we proceed towards GHC2023?

So far we have * Chris, Adam and me in favor * Vlad, Arnaud and Simon PJ against and silence from the rest. And I just noticed that I wrote “April 5” when I meant “February 5” (for the usual 2 week period). Ups, sorry. So in theory maybe the others were planning to respond later? Anyways, given that there is neither consensus (so it’s not clear what to do), nor much discussion (so it’s not clear that many care), in the interest of getting things done, I’ll just declare this as rejected – it’s not a bike-shedding-like issue where close votes are a good way to make a call, but it’s rather something that, if it happens, should have broad support in the committee anyways. (If this was premature and overreachy and suddenly a strong majority in favor emerges we can still change our collective mind.) Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Chris Dornan

12:33 p.m.

Although I was in favour of us proceeding I agree that in the face of such ambivalence it is probably best to assume that we won't 'release' GHC2023. I am hedging a bit -- those of us in favour might muster an argument later in the year and explain exactly what we want GHC2023 for, and turn the doubters into believers, but the onus will be on us to do that, and until then we can focus on other matters.

...

On 5 Feb 2023, at 16:22, Joachim Breitner wrote:

Hi,

Am Sonntag, dem 22.01.2023 um 13:40 +0100 schrieb Joachim Breitner:

...
Instead, please cast your vote until Apri 5 (but preferrably earlier) on the question:

Should we proceed towards GHC2023?

So far we have

* Chris, Adam and me in favor * Vlad, Arnaud and Simon PJ against

and silence from the rest. And I just noticed that I wrote “April 5” when I meant “February 5” (for the usual 2 week period). Ups, sorry.

So in theory maybe the others were planning to respond later?

Anyways, given that there is neither consensus (so it’s not clear what to do), nor much discussion (so it’s not clear that many care), in the interest of getting things done, I’ll just declare this as rejected – it’s not a bike-shedding-like issue where close votes are a good way to make a call, but it’s rather something that, if it happens, should have broad support in the committee anyways.

(If this was premature and overreachy and suddenly a strong majority in favor emerges we can still change our collective mind.)

Cheers, Joachim

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

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Richard Eisenberg

8:55 p.m.

Instead of focusing narrowly on GHC2023, I would much rather harness the activity that arose over https://docs.google.com/document/d/1_-hPh8BRhKNlzM0dC1IRSmjCqPym9mXx9NjC7jUl... and get that discussion in a state where we can actually turn it into something resembling a policy. I think that's why I didn't vote on the GHC2023 question. I feel unable to have an opinion about GHC2023 until we sort out the larger question. I seem to recall some email suggesting Arnaud would pilot the discussion to a conclusion. That would be great. But if I'm either dreaming that or Arnaud is actually unavailable, I can volunteer to do this. This would take the place of active work within GHC for me for a few weeks, but I actually think that's OK and a good use of my time. Richard

...

On Feb 5, 2023, at 12:33 PM, Chris Dornan wrote:

Although I was in favour of us proceeding I agree that in the face of such ambivalence it is probably best to assume that we won't 'release' GHC2023.

I am hedging a bit -- those of us in favour might muster an argument later in the year and explain exactly what we want GHC2023 for, and turn the doubters into believers, but the onus will be on us to do that, and until then we can focus on other matters.

...
On 5 Feb 2023, at 16:22, Joachim Breitner wrote:

Hi,

Am Sonntag, dem 22.01.2023 um 13:40 +0100 schrieb Joachim Breitner:

...
Instead, please cast your vote until Apri 5 (but preferrably earlier) on the question:

Should we proceed towards GHC2023?

So far we have

* Chris, Adam and me in favor * Vlad, Arnaud and Simon PJ against

and silence from the rest. And I just noticed that I wrote “April 5” when I meant “February 5” (for the usual 2 week period). Ups, sorry.

So in theory maybe the others were planning to respond later?

Anyways, given that there is neither consensus (so it’s not clear what to do), nor much discussion (so it’s not clear that many care), in the interest of getting things done, I’ll just declare this as rejected – it’s not a bike-shedding-like issue where close votes are a good way to make a call, but it’s rather something that, if it happens, should have broad support in the committee anyways.

(If this was premature and overreachy and suddenly a strong majority in favor emerges we can still change our collective mind.)

Cheers, Joachim

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

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Arnaud Spiwack

10 Feb 10 Feb

11 a.m.

Because I've been very silent here: I've spoken with Richard, and I'll be the person handling the document, as promised. I really wished I could have gotten to it earlier, but I've had a very intense couple of weeks which didn't afford me the sort of focus that this task deserves. That being said, I have a plan, so a bunch of polls coming to you Very Soon™. /Arnaud On Mon, 6 Feb 2023 at 02:56, Richard Eisenberg wrote:

...

Instead of focusing narrowly on GHC2023, I would much rather harness the activity that arose over https://docs.google.com/document/d/1_-hPh8BRhKNlzM0dC1IRSmjCqPym9mXx9NjC7jUl... and get that discussion in a state where we can actually turn it into something resembling a policy. I think that's why I didn't vote on the GHC2023 question. I feel unable to have an opinion about GHC2023 until we sort out the larger question.

I seem to recall some email suggesting Arnaud would pilot the discussion to a conclusion. That would be great. But if I'm either dreaming that or Arnaud is actually unavailable, I can volunteer to do this. This would take the place of active work within GHC for me for a few weeks, but I actually think that's OK and a good use of my time.

Richard

...
On Feb 5, 2023, at 12:33 PM, Chris Dornan wrote:

Although I was in favour of us proceeding I agree that in the face of such ambivalence it is probably best to assume that we won't 'release' GHC2023.

I am hedging a bit -- those of us in favour might muster an argument later in the year and explain exactly what we want GHC2023 for, and turn the doubters into believers, but the onus will be on us to do that, and until then we can focus on other matters.

...
On 5 Feb 2023, at 16:22, Joachim Breitner wrote:

Hi,

Am Sonntag, dem 22.01.2023 um 13:40 +0100 schrieb Joachim Breitner:

...
Instead, please cast your vote until Apri 5 (but preferrably earlier) on the question:

Should we proceed towards GHC2023?

So far we have

* Chris, Adam and me in favor * Vlad, Arnaud and Simon PJ against

and silence from the rest. And I just noticed that I wrote “April 5” when I meant “February 5” (for the usual 2 week period). Ups, sorry.

So in theory maybe the others were planning to respond later?

Anyways, given that there is neither consensus (so it’s not clear what to do), nor much discussion (so it’s not clear that many care), in the interest of getting things done, I’ll just declare this as rejected – it’s not a bike-shedding-like issue where close votes are a good way to make a call, but it’s rather something that, if it happens, should have broad support in the committee anyways.

(If this was premature and overreachy and suddenly a strong majority in favor emerges we can still change our collective mind.)

Cheers, Joachim

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

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

830

Age (days ago)

849

Last active (days ago)

List overview

Download

11 comments

7 participants

participants (7)

Adam Gundry
Arnaud Spiwack
Chris Dornan
Joachim Breitner
Richard Eisenberg
Simon Peyton Jones
Vladislav Zavialov

Call for votes: Shall we have GHC2023

tags

participants (7)