Adding Tom Ellis (thank you Jakob). Simon On Tue, 1 Nov 2022 at 11:43, Simon Peyton Jones wrote:

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.

Indeed, we originally said we'd review GHC20xx annually, but I think we might want to consult the community to see if that is too often. There has been an interesting thread https://discourse.haskell.org/t/quo-vadis-ghc2023/5220on the Haskell Discourse.

The HF Stability Working Group discussed this on Monday, and I think Tom Ellis (a member of the SWG) is willing to lead a consultation. I think that would be great -- we have no axe to grind here, and I think we'll be delighted to do whatever makes the maximal number of people happy.

Tom (cc'd) will write with more info shortly. Sound OK?

Simon

On Mon, 24 Oct 2022 at 20:49, Joachim Breitner wrote:

...

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 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@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

Thanks Simon. On reflection, I'm not particularly motivated to consult the community because the concerns I have impinge most strongly on members of the community who are distant from where a consultation could easily reach, and on non-but-potential-members of the community who are getting a false impression from afar. I will content myself with elaborating on my concerns and then leaving it to the steering committee to take them into account if they see fit. To set the scene, everything I write below is presented from the point of view of someone who wishes Haskell usage to increase and believes that we can't increase Haskell usage by appealing to people who are already comfortable with the way the Haskell ecosystem currently works: we've already got most of those people. For the ten years that I have been in the community, Haskell has had a (false) reputation, to outsiders, as a fragmented language with multiple mysterious things called "language extensions" each of which fractures the language in an incompatible way. "It's impossible to learn Haskell because there are so many incompatible Haskells" they say. It may be hard to believe that this perception exists: as users of GHC we know that there are very few extensions that introduce any incompatibility with others; extensions typically just remove unneccesary restrictions. But, for those of you who don't spend far-too-much of your time on discussion fora such as Hacker News and Reddit, I can guarantee to you that this objection to Haskell comes up *a lot*. Haskell also has, to both insiders and outsiders, a (true) reputation for being an unstable moving target. "It's impossible to learn or use Haskell because the language and libraries keep changing", they say. This one is easier to believe. GHC2021 is a wonderful way of dealing with all of the first and part of the second objection! I can now respond to complaints of language fragmentation and language instability by simply saying "Turn on GHC2021 and be happy". This is great news! (GHC2021 doesn't deal with instability in libraries of course, but I'm pleased that there are many people making efforts in that area too.) I am concerned that GHC2023 would weaken the power of my rejoinder "Turn on GHC2021 and be happy". Now I am at risk of the responses "But why not GHC2023?", "Haskell introduced a new, incompatible language just two years after standardising on GHC2021", "I just spent my precious time learning GHC2021, now I have to spend time learning GHC2023.". Sure, these responses are based on misunderstandings of the technical details. But perceptions really, really matter! If we want a large increase in Haskell usage then we have to take perceptions into account. We can't substantially increase Haskell usage any more by appealing just to our techncial excellence. If we choose to prioritise business-as-usual, that is, the incorporation of highly technically excellent features on a regular basis, with no thought to the costs, then the consequence will be Haskellers-as-usual: people who value that kind of thing in spite of the costs. We already have most of those people. We can't increase Haskell adoption that way. If we choose to change tack then we have the chance of changing the types of people we pick up as new Haskellers, from among those who would never otherwise have considered the language. To put it pithily, Joachim writes in a sibling thread "The point of the GHC20xx series is to get (proven, useful, uncontroversial) goodies into the hands of our users". Are members of the Haskell community, and indeed non-but-potential-members, screaming out for new "goodies"? Or are they screaming out for a brief respite from the unforgiving churn of the Haskell ecosystem, both real and not-real-but-perceived. My experience of the last ten years tells me it's the latter. To be clear, I personally am very much looking forward to more highly technically excellent features, including the exciting ongoing work on dependent types, WASM, GHCJS, and so on. It's one of the aspects of the community that really inspires and excites me! I personally can tolerate the churn. But I don't want those things at the *cost* of continuing to push away potential new users who are currently peering over the fence, discouraged because they can't tolerate the churn that they see, real or perceived. Now, with my stability hat on, looking from the point of view of process design, it's actually *better* for changes to happen in small increments, so maybe having GHC20xx every year is actually *better* than every five years. I don't wish to advocate for one choice or another. Rather I wish to advocate for the point of view that: Technical excellence matters. Stability and the perception of stability matter too. Tom On Tue, 1 Nov 2022 at 11:43, Simon Peyton Jones wrote:

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.

Indeed, we originally said we'd review GHC20xx annually, but I think we might want to consult the community to see if that is too often. There has been an interesting thread https://discourse.haskell.org/t/quo-vadis-ghc2023/5220on the Haskell Discourse.

The HF Stability Working Group discussed this on Monday, and I think Tom Ellis (a member of the SWG) is willing to lead a consultation. I think that would be great -- we have no axe to grind here, and I think we'll be delighted to do whatever makes the maximal number of people happy.

Tom (cc'd) will write with more info shortly. Sound OK?

Simon

On Mon, 24 Oct 2022 at 20:49, Joachim Breitner wrote:

...

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 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…)

So I think a better target is releasing a new edition of the Haskell language, dubbed GHC2024, in 2024.

I'd be happy with that too. Simon On Fri, 11 Nov 2022 at 20:45, Richard Eisenberg wrote:

I somehow like 3 years more than 2 here. One reason: the feedback we would like has yet to materialize, because GHC2021 is still not widely available in industry. Industry is slow! (Example: earlier today I had trouble compiling GHC on my work machine because it uses TeXLive 2012, and sphinx has advanced beyond that.)

But I also think there's a terminology problem: extension vs language. Why are some features part of the language and some extensions? It's all because of history. But today's programmers do not care about the history.

There is good news here: GHC2021 is enabled in cabal with `default-language`. And the pragma in Haskell is called {-# LANGUAGE GHC2021 #-}. Hooray!

So I think a better target is releasing a new edition of the Haskell language, dubbed GHC2024, in 2024.

Richard

...

On Nov 5, 2022, at 8:24 AM, Tom Ellis wrote:

Thanks Simon.

On reflection, I'm not particularly motivated to consult the community because the concerns I have impinge most strongly on members of the community who are distant from where a consultation could easily reach, and on non-but-potential-members of the community who are getting a false impression from afar.

I will content myself with elaborating on my concerns and then leaving it to the steering committee to take them into account if they see fit. To set the scene, everything I write below is presented from the point of view of someone who wishes Haskell usage to increase and believes that we can't increase Haskell usage by appealing to people who are already comfortable with the way the Haskell ecosystem currently works: we've already got most of those people.

For the ten years that I have been in the community, Haskell has had a (false) reputation, to outsiders, as a fragmented language with multiple mysterious things called "language extensions" each of which fractures the language in an incompatible way. "It's impossible to learn Haskell because there are so many incompatible Haskells" they say. It may be hard to believe that this perception exists: as users of GHC we know that there are very few extensions that introduce any incompatibility with others; extensions typically just remove unneccesary restrictions. But, for those of you who don't spend far-too-much of your time on discussion fora such as Hacker News and Reddit, I can guarantee to you that this objection to Haskell comes up *a lot*.

Haskell also has, to both insiders and outsiders, a (true) reputation for being an unstable moving target. "It's impossible to learn or use Haskell because the language and libraries keep changing", they say. This one is easier to believe.

GHC2021 is a wonderful way of dealing with all of the first and part of the second objection! I can now respond to complaints of language fragmentation and language instability by simply saying "Turn on GHC2021 and be happy". This is great news!

(GHC2021 doesn't deal with instability in libraries of course, but I'm pleased that there are many people making efforts in that area too.)

I am concerned that GHC2023 would weaken the power of my rejoinder "Turn on GHC2021 and be happy". Now I am at risk of the responses "But why not GHC2023?", "Haskell introduced a new, incompatible language just two years after standardising on GHC2021", "I just spent my precious time learning GHC2021, now I have to spend time learning GHC2023.". Sure, these responses are based on misunderstandings of the technical details. But perceptions really, really matter! If we want a large increase in Haskell usage then we have to take perceptions into account. We can't substantially increase Haskell usage any more by appealing just to our techncial excellence.

If we choose to prioritise business-as-usual, that is, the incorporation of highly technically excellent features on a regular basis, with no thought to the costs, then the consequence will be Haskellers-as-usual: people who value that kind of thing in spite of the costs. We already have most of those people. We can't increase Haskell adoption that way. If we choose to change tack then we have the chance of changing the types of people we pick up as new Haskellers, from among those who would never otherwise have considered the language.

To put it pithily, Joachim writes in a sibling thread "The point of the GHC20xx series is to get (proven, useful, uncontroversial) goodies into the hands of our users". Are members of the Haskell community, and indeed non-but-potential-members, screaming out for new "goodies"? Or are they screaming out for a brief respite from the unforgiving churn of the Haskell ecosystem, both real and not-real-but-perceived. My experience of the last ten years tells me it's the latter.

To be clear, I personally am very much looking forward to more highly technically excellent features, including the exciting ongoing work on dependent types, WASM, GHCJS, and so on. It's one of the aspects of the community that really inspires and excites me! I personally can tolerate the churn. But I don't want those things at the *cost* of continuing to push away potential new users who are currently peering over the fence, discouraged because they can't tolerate the churn that they see, real or perceived.

Now, with my stability hat on, looking from the point of view of process design, it's actually *better* for changes to happen in small increments, so maybe having GHC20xx every year is actually *better* than every five years. I don't wish to advocate for one choice or another. Rather I wish to advocate for the point of view that:

Technical excellence matters. Stability and the perception of stability matter too.

Tom

On Tue, 1 Nov 2022 at 11:43, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

...

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.

Indeed, we originally said we'd review GHC20xx annually, but I think we might want to consult the community to see if that is too often. There has been an interesting thread https://discourse.haskell.org/t/quo-vadis-ghc2023/5220on the Haskell Discourse.

The HF Stability Working Group discussed this on Monday, and I think Tom Ellis (a member of the SWG) is willing to lead a consultation. I think that would be great -- we have no axe to grind here, and I think we'll be delighted to do whatever makes the maximal number of people happy.

Tom (cc'd) will write with more info shortly. Sound OK?

Simon

On Mon, 24 Oct 2022 at 20:49, Joachim Breitner < mail@joachim-breitner.de> wrote:

...

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 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…)

---

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

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