I have been a strongly in favour of minimising surprises but I mildly resistant to this proposal. After GHC2021 broke my code quite severly (though PolyKinds) there was an initial adjustment phase but I quickly got used to specifying the exact language I want to use everywhere. Indeed the propensity for GHCi to pick up the new breakage caused some surprises but I quickly adjusted when I realised what was going on. The point is not that change is bad but change that is difficult to anticipate and control is bad. I now see the GHC adoption of the new default languages, that can very selectively break things when needed, as a fantastic development. It allows us to roll out changes in a very controlled way where at synchronisation points that are easy to understand and where developers retain control. This strikes me as a really great sweet spot for Haskell. If we make this scheme more complicated by making some the tools adopt languages on different schedules then it risks creating confusion. Folks that want to tie down advanced features strike me as just the kind that should find it easy to fill out the appropriate settings in configuration files. So I say lets get this rolled out ASAP (as Adam says) but roll it out consistently everywhere. Chris

On 15 Feb 2024, at 09:15, Simon Peyton Jones wrote:

I'm ok with this proposal. The whole concept of a default language seems a bit flaky to me, if we are going to start warning any time someone doesn't explicitly specify an explicit addition. While this is settling down, causing minimum disruption is good.

Simon

On Thu, 15 Feb 2024 at 08:50, Adam Gundry mailto:adam@well-typed.com> wrote:

...

Dear committee,

In #632, I propose amending the GHC2024 proposal to specify that the default language used by ghc/ghci when run directly will remain GHC2021 for now, since changing to GHC2024 is not backwards compatible. (This does not affect Cabal packages either way, since Cabal specifies its own default.)

https://github.com/ghc-proposals/ghc-proposals/pull/632

https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals...

On the discussion thread, some people expressed a preference that GHC should default to the latest language edition anyway. There is also Richard's suggestion of wider changes of approach in #636. However, given that the GHC 9.10 fork date is fast approaching, introducing GHC2024 but not making it the default seems like the best short-term solution to me. We can always reassess our approach to this for future releases as part of the wider discussion.

If you object to the proposed approach, please speak up ASAP. Otherwise I plan to merge in a week or so.

Cheers,

Adam

-- 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 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto: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

Sorry, I misunderstood the proposal — for some reason I thought we were going to delay the default for ghci. If we think the new language is going to be particularly disruptive then we might want a transition period where it is available before making it the default — I really have no objection to this at all in general. I will just suggest that we might want to enable these defaults quite aggressively — and I say this having been bitten by GHC2021 myself. We are committed to breaking stuff — is there much to be gained by delaying. Is it not going to delay take-up? It makes the whole process more complicated. Chris

On 15 Feb 2024, at 16:08, Simon Peyton Jones wrote:

I'm not understanding your point, Chris.

I think we are planning to increasingly encourage people to specify an explicit language edition for everything. (Indeed there is discussion of an on-by-default warning that complains if you don't.) For these users, the "default language edition" is irrelevant.

So the only issue is people who don't specify a language edition at all. Changing the default language edition risks breaking their code. Why would we do that? What compelling reason is there for breaking code that we don't have to break?

For the short term, GHC2024 is particularly likely to break code We have not yet educated our users to use explicit language editions So making GHC2024 be the default language for GHC 9.10 seems (to me) to lead to entirely-unnecessary breakage, with no compelling reason to do so.

Simon

On Thu, 15 Feb 2024 at 13:21, Chris Dornan mailto:chris@chrisdornan.com> wrote:

...

I have been a strongly in favour of minimising surprises but I mildly resistant to this proposal.

After GHC2021 broke my code quite severly (though PolyKinds) there was an initial adjustment phase but I quickly got used to specifying the exact language I want to use everywhere. Indeed the propensity for GHCi to pick up the new breakage caused some surprises but I quickly adjusted when I realised what was going on.

The point is not that change is bad but change that is difficult to anticipate and control is bad.

I now see the GHC adoption of the new default languages, that can very selectively break things when needed, as a fantastic development. It allows us to roll out changes in a very controlled way where at synchronisation points that are easy to understand and where developers retain control. This strikes me as a really great sweet spot for Haskell.

If we make this scheme more complicated by making some the tools adopt languages on different schedules then it risks creating confusion. Folks that want to tie down advanced features strike me as just the kind that should find it easy to fill out the appropriate settings in configuration files.

So I say lets get this rolled out ASAP (as Adam says) but roll it out consistently everywhere.

Chris

...

On 15 Feb 2024, at 09:15, Simon Peyton Jones mailto:simon.peytonjones@gmail.com> wrote:

I'm ok with this proposal. The whole concept of a default language seems a bit flaky to me, if we are going to start warning any time someone doesn't explicitly specify an explicit addition. While this is settling down, causing minimum disruption is good.

Simon

On Thu, 15 Feb 2024 at 08:50, Adam Gundry mailto:adam@well-typed.com> wrote:

...

Dear committee,

In #632, I propose amending the GHC2024 proposal to specify that the default language used by ghc/ghci when run directly will remain GHC2021 for now, since changing to GHC2024 is not backwards compatible. (This does not affect Cabal packages either way, since Cabal specifies its own default.)

https://github.com/ghc-proposals/ghc-proposals/pull/632

https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals...

On the discussion thread, some people expressed a preference that GHC should default to the latest language edition anyway. There is also Richard's suggestion of wider changes of approach in #636. However, given that the GHC 9.10 fork date is fast approaching, introducing GHC2024 but not making it the default seems like the best short-term solution to me. We can always reassess our approach to this for future releases as part of the wider discussion.

If you object to the proposed approach, please speak up ASAP. Otherwise I plan to merge in a week or so.

Cheers,

Adam

-- 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 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto: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 mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Thanks everyone for sharing your thoughts. I would point out that this is not just about "the handful of people that have ghci scripts" but rather anyone compiling modules with ghc directly (not using Cabal). Were it about ghci alone, I agree that the latest language edition would be preferable. But it seems likely to be a larger class, e.g. including educators teaching Haskell, and users with small programs where they have not created a Cabal package. Adam On 16/02/2024 08:36, Arnaud Spiwack wrote:

(I won't be able to follow this conversation as I'll be on holiday for the next week so dropping my thoughts a little unstructured)

I'm not keen on giving people gratuitous work. I think staging making GHC2024 the default borders on gratuitous work (because I'm not convinced that the transition period will achieve anything, but on the other hand, it gives us a little bit of time to warn people). The idea that we will want to make a decision for each edition in the future regarding whether it's to be the default is definitely gratuitous work (I can be convinced otherwise, of course: this is my current train of thoughts). Generally speaking, all cabal projects have a fixed `default-language` (which, we learnt, is Haskell98 if omitted). So really we're doing this for the handful of people that have ghci scripts. And we're making everybody else's life worse (because ghci is worse). I'm, obviously, a strong believer in the power of defaults.

So, anyway, without having had much time to think about this: maybe ok for staging GHC2024 in particular, just this once. I think it's a bad idea, but not a hill I'll die on. The rest of the proposal I'm rather opposed to.

On Thu, 15 Feb 2024 at 20:51, Chris Dornan mailto:chris@chrisdornan.com> wrote:

Sorry, I misunderstood the proposal — for some reason I thought we were going to delay the default for ghci.

If we think the new language is going to be particularly disruptive then we might want a transition period where it is available before making it the default — I really have no objection to this at all in general.

I will just suggest that we might want to enable these defaults quite aggressively — and I say this having been bitten by GHC2021 myself. We are committed to breaking stuff — is there much to be gained by delaying. Is it not going to delay take-up? It makes the whole process more complicated.

Chris

...

On 15 Feb 2024, at 16:08, Simon Peyton Jones mailto:simon.peytonjones@gmail.com> wrote:

I'm not understanding  your point, Chris.

I think we are planning to increasingly encourage people to specify an explicit language edition for everything.  (Indeed there is discussion of an on-by-default warning that complains if you don't.)  For these users, the "default language edition" is irrelevant.

So the only issue is people who don't specify a language edition at all.   Changing the default language edition risks breaking their code.  Why would we do that? What compelling reason is there for breaking code that we don't have to break?

For the short term,

* GHC2024 is particularly likely to break code * We have not yet educated our users to use explicit language editions

So making GHC2024 be the default language for GHC 9.10 seems (to me) to lead to entirely-unnecessary breakage, with no compelling reason to do so.

Simon

On Thu, 15 Feb 2024 at 13:21, Chris Dornan mailto:chris@chrisdornan.com> wrote:

I have been a strongly in favour of minimising surprises but I mildly resistant to this proposal.

After GHC2021 broke my code quite severly (though PolyKinds) there was an initial adjustment phase but I quickly got used to specifying the exact language I want to use everywhere. Indeed the propensity for GHCi to pick up the new breakage caused some surprises but I quickly adjusted when I realised what was going on.

The point is not that change is bad but change that is difficult to anticipate and control is bad.

I now see the GHC adoption of the new default languages, that can very selectively break things when needed, as a fantastic development. It allows us to roll out changes in a very controlled way where at synchronisation points that are easy to understand and where developers retain control. This strikes me as a really great sweet spot for Haskell.

If we make this scheme more complicated by making some the tools adopt languages on different schedules then it risks creating confusion. Folks that want to tie down advanced features strike me as just the kind that should find it easy to fill out the appropriate settings in configuration files.

So I say lets get this rolled out ASAP (as Adam says) but roll it out consistently everywhere.

Chris

...

On 15 Feb 2024, at 09:15, Simon Peyton Jones mailto:simon.peytonjones@gmail.com> wrote:

I'm ok with this proposal.  The whole concept of a default language seems a bit flaky to me, if we are going to start warning any time someone doesn't explicitly specify an explicit addition.  While this is settling down, causing minimum disruption is good.

Simon

On Thu, 15 Feb 2024 at 08:50, Adam Gundry mailto:adam@well-typed.com> wrote:

Dear committee,

In #632, I propose amending the GHC2024 proposal to specify that the default language used by ghc/ghci when run directly will remain GHC2021 for now, since changing to GHC2024 is not backwards compatible. (This does not affect Cabal packages either way, since Cabal specifies its own default.)

https://github.com/ghc-proposals/ghc-proposals/pull/632 https://github.com/ghc-proposals/ghc-proposals/pull/632

https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals... https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals...

On the discussion thread, some people expressed a preference that GHC should default to the latest language edition anyway. There is also Richard's suggestion of wider changes of approach in #636. However, given that the GHC 9.10 fork date is fast approaching, introducing GHC2024 but not making it the default seems like the best short-term solution to me. We can always reassess our approach to this for future releases as part of the wider discussion.

If you object to the proposed approach, please speak up ASAP. Otherwise I plan to merge in a week or so.

Cheers,

Adam

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

Apologies for letting this thread linger. The current de facto situation is that GHC 9.10 will ship with GHC2024 available but not enabled by default. (Given the timing, it did not seem feasible to change the default, and but leaving GHC2024 out of the release entirely would seem unnecessary.) Several people have expressed the opinion that we should actively plan to switch the default, to benefit one-off use (especially in ghci), rather than simply leaving GHC2021 as the default indefinitely. So the question is what level of messaging is appropriate before that happens. I can see a few options, none of which are entirely satisfying: * Mention in the release notes (done for 9.10, and easily done in the next release). * Add an off-by-default warning about failure to specify a language edition (maybe in -Wall or -Wcompat). Unclear this benefits many people because if they aren't specifying a language edition or reading the release notes, they may well not be enabling non-default warnings either. * Enable the warning about failure to specify a language edition by default. A bit noisy for ad hoc use. * Add a warning where NoMonoLocalBinds is used and changing to MonoLocalBinds would break the program (since this is the most likely source of breakage in practice). This warning could be enabled by default if no language edition is specified. Nice for users, but probably quite a bit of implementation overhead, so unclear if it would be implemented. * Wait for a super-major release (e.g. the 10.x series) before changing the default language. Not clear when this will be. Any other options? Opinions? Adam On 19/02/2024 21:34, Eric Seidel wrote:

It seems to me that this particular proposal could make sense tactically, but I agree with Chris and Arnaud that it feels like the wrong thing strategically.

I don't see us getting away from a notion of a "default language". GCC/Clang similarly implement many C/C++ standards and let users choose, but still define a default standard per compiler version. And this default changes across compiler releases. Forcing even adhoc ghc[i] sessions to specify a language standard feels excessive.

Thus, we need *some* cadence for updating the default language. It could be that GHC 9.10 is too soon to make that change, but we should commit to making the change at some point, with proper messaging.

Eric

On Fri, Feb 16, 2024, at 03:08, Adam Gundry wrote:

...

Thanks everyone for sharing your thoughts.

I would point out that this is not just about "the handful of people that have ghci scripts" but rather anyone compiling modules with ghc directly (not using Cabal). Were it about ghci alone, I agree that the latest language edition would be preferable. But it seems likely to be a larger class, e.g. including educators teaching Haskell, and users with small programs where they have not created a Cabal package.

Adam

On 16/02/2024 08:36, Arnaud Spiwack wrote:

...

(I won't be able to follow this conversation as I'll be on holiday for the next week so dropping my thoughts a little unstructured)

I'm not keen on giving people gratuitous work. I think staging making GHC2024 the default borders on gratuitous work (because I'm not convinced that the transition period will achieve anything, but on the other hand, it gives us a little bit of time to warn people). The idea that we will want to make a decision for each edition in the future regarding whether it's to be the default is definitely gratuitous work (I can be convinced otherwise, of course: this is my current train of thoughts). Generally speaking, all cabal projects have a fixed `default-language` (which, we learnt, is Haskell98 if omitted). So really we're doing this for the handful of people that have ghci scripts. And we're making everybody else's life worse (because ghci is worse). I'm, obviously, a strong believer in the power of defaults.

So, anyway, without having had much time to think about this: maybe ok for staging GHC2024 in particular, just this once. I think it's a bad idea, but not a hill I'll die on. The rest of the proposal I'm rather opposed to.

On Thu, 15 Feb 2024 at 20:51, Chris Dornan mailto:chris@chrisdornan.com> wrote:

Sorry, I misunderstood the proposal — for some reason I thought we were going to delay the default for ghci.

If we think the new language is going to be particularly disruptive then we might want a transition period where it is available before making it the default — I really have no objection to this at all in general.

I will just suggest that we might want to enable these defaults quite aggressively — and I say this having been bitten by GHC2021 myself. We are committed to breaking stuff — is there much to be gained by delaying. Is it not going to delay take-up? It makes the whole process more complicated.

Chris

...

On 15 Feb 2024, at 16:08, Simon Peyton Jones mailto:simon.peytonjones@gmail.com> wrote:

I'm not understanding  your point, Chris.

I think we are planning to increasingly encourage people to specify an explicit language edition for everything.  (Indeed there is discussion of an on-by-default warning that complains if you don't.)  For these users, the "default language edition" is irrelevant.

So the only issue is people who don't specify a language edition at all.   Changing the default language edition risks breaking their code.  Why would we do that? What compelling reason is there for breaking code that we don't have to break?

For the short term,

* GHC2024 is particularly likely to break code * We have not yet educated our users to use explicit language editions

So making GHC2024 be the default language for GHC 9.10 seems (to me) to lead to entirely-unnecessary breakage, with no compelling reason to do so.

Simon

On Thu, 15 Feb 2024 at 13:21, Chris Dornan mailto:chris@chrisdornan.com> wrote:

I have been a strongly in favour of minimising surprises but I mildly resistant to this proposal.

After GHC2021 broke my code quite severly (though PolyKinds) there was an initial adjustment phase but I quickly got used to specifying the exact language I want to use everywhere. Indeed the propensity for GHCi to pick up the new breakage caused some surprises but I quickly adjusted when I realised what was going on.

The point is not that change is bad but change that is difficult to anticipate and control is bad.

I now see the GHC adoption of the new default languages, that can very selectively break things when needed, as a fantastic development. It allows us to roll out changes in a very controlled way where at synchronisation points that are easy to understand and where developers retain control. This strikes me as a really great sweet spot for Haskell.

If we make this scheme more complicated by making some the tools adopt languages on different schedules then it risks creating confusion. Folks that want to tie down advanced features strike me as just the kind that should find it easy to fill out the appropriate settings in configuration files.

So I say lets get this rolled out ASAP (as Adam says) but roll it out consistently everywhere.

Chris

...

On 15 Feb 2024, at 09:15, Simon Peyton Jones mailto:simon.peytonjones@gmail.com> wrote:

I'm ok with this proposal.  The whole concept of a default language seems a bit flaky to me, if we are going to start warning any time someone doesn't explicitly specify an explicit addition.  While this is settling down, causing minimum disruption is good.

Simon

On Thu, 15 Feb 2024 at 08:50, Adam Gundry mailto:adam@well-typed.com> wrote:

Dear committee,

In #632, I propose amending the GHC2024 proposal to specify that the default language used by ghc/ghci when run directly will remain GHC2021 for now, since changing to GHC2024 is not backwards compatible. (This does not affect Cabal packages either way, since Cabal specifies its own default.)

https://github.com/ghc-proposals/ghc-proposals/pull/632 https://github.com/ghc-proposals/ghc-proposals/pull/632

https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals... https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals...

On the discussion thread, some people expressed a preference that GHC should default to the latest language edition anyway. There is also Richard's suggestion of wider changes of approach in #636. However, given that the GHC 9.10 fork date is fast approaching, introducing GHC2024 but not making it the default seems like the best short-term solution to me. We can always reassess our approach to this for future releases as part of the wider discussion.

If you object to the proposed approach, please speak up ASAP. Otherwise I plan to merge in a week or so.

Cheers,

Adam

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

I think we should thus encourage them. Because that greatly increases the chances that if the module compiles with GHC(X) then it'll compile with GHC(X+k).

Very much so, in my opinion. In libraries, and other code that must remain stable.

If they do this, then the "default language edition" barely matters.

I'd say defaults always matter a lot. They communicate what we consider to be normal. I've expressed before that I believe it's crucially important that “normal Haskell” be equated with the latest edition (this is a hill I'm willing to die on). If the default is anything else, we're communicating the wrong thing, creating confusion. Now there are several levels of defaults: what Cabal and Stack chooses as default for `cabal init`/`stack new`. This we don't have control over (except maybe frowning and looking very cross at the authors). I still believe it should point to the latest edition. Then there's the default when running GHC. This mostly only matter when not building via Cabal. Which, in my experience, is only for throwaway script (tiny experiment, very often with ghci). There I also want to use normal Haskell. And, just as importantly, I want the bells and the whistles of recent developments. Stability isn't a concern, I just want to get started efficiently. On Thu, 21 Mar 2024 at 11:08, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

It's hard to answer this without addressing the following question

- Do we want to actively encourage Haskell users to specify a language edition for every module (via a LANGUAGE pragma, cabal file, or command line option)?

I think we should thus encourage them. Because that greatly increases the chances that if the module compiles with GHC(X) then it'll compile with GHC(X+k).

If they do this, then the "default language edition" barely matters.

Indeed, I want to question the merit of having a "default language edition" at all. Suppose the default language edition was GHC2021 forever. All by itself that would encourage the use of an explicit language edition, to get hold a coherent bundle of extensions beyond GHC2021. We might not need to do any more than that.

Simon

On Thu, 21 Mar 2024 at 09:08, Adam Gundry wrote:

...

Apologies for letting this thread linger.

The current de facto situation is that GHC 9.10 will ship with GHC2024 available but not enabled by default. (Given the timing, it did not seem feasible to change the default, and but leaving GHC2024 out of the release entirely would seem unnecessary.)

Several people have expressed the opinion that we should actively plan to switch the default, to benefit one-off use (especially in ghci), rather than simply leaving GHC2021 as the default indefinitely. So the question is what level of messaging is appropriate before that happens. I can see a few options, none of which are entirely satisfying:

* Mention in the release notes (done for 9.10, and easily done in the next release).

* Add an off-by-default warning about failure to specify a language edition (maybe in -Wall or -Wcompat). Unclear this benefits many people because if they aren't specifying a language edition or reading the release notes, they may well not be enabling non-default warnings either.

* Enable the warning about failure to specify a language edition by default. A bit noisy for ad hoc use.

* Add a warning where NoMonoLocalBinds is used and changing to MonoLocalBinds would break the program (since this is the most likely source of breakage in practice). This warning could be enabled by default if no language edition is specified. Nice for users, but probably quite a bit of implementation overhead, so unclear if it would be implemented.

* Wait for a super-major release (e.g. the 10.x series) before changing the default language. Not clear when this will be.

Any other options? Opinions?

Adam

...

It seems to me that this particular proposal could make sense tactically, but I agree with Chris and Arnaud that it feels like the wrong thing strategically.

I don't see us getting away from a notion of a "default language". GCC/Clang similarly implement many C/C++ standards and let users choose, but still define a default standard per compiler version. And this default changes across compiler releases. Forcing even adhoc ghc[i] sessions to specify a language standard feels excessive.

Thus, we need *some* cadence for updating the default language. It could be that GHC 9.10 is too soon to make that change, but we should commit to making the change at some point, with proper messaging.

Eric

On Fri, Feb 16, 2024, at 03:08, Adam Gundry wrote:

...

Thanks everyone for sharing your thoughts.

I would point out that this is not just about "the handful of people that have ghci scripts" but rather anyone compiling modules with ghc directly (not using Cabal). Were it about ghci alone, I agree that the latest language edition would be preferable. But it seems likely to be a larger class, e.g. including educators teaching Haskell, and users with small programs where they have not created a Cabal package.

Adam

On 16/02/2024 08:36, Arnaud Spiwack wrote:

...

(I won't be able to follow this conversation as I'll be on holiday for the next week so dropping my thoughts a little unstructured)

I'm not keen on giving people gratuitous work. I think staging making GHC2024 the default borders on gratuitous work (because I'm not convinced that the transition period will achieve anything, but on the other hand, it gives us a little bit of time to warn people). The idea that we will want to make a decision for each edition in the future regarding whether it's to be the default is definitely gratuitous work (I can be convinced otherwise, of course: this is my current train of thoughts). Generally speaking, all cabal projects have a fixed `default-language` (which, we learnt, is Haskell98 if omitted). So really we're doing

...

...

...

for the handful of people that have ghci scripts. And we're making everybody else's life worse (because ghci is worse). I'm, obviously, a strong believer in the power of defaults.

So, anyway, without having had much time to think about this: maybe ok for staging GHC2024 in particular, just this once. I think it's a bad idea, but not a hill I'll die on. The rest of the proposal I'm rather opposed to.

On Thu, 15 Feb 2024 at 20:51, Chris Dornan mailto:chris@chrisdornan.com> wrote:

Sorry, I misunderstood the proposal — for some reason I thought we were going to delay the default for ghci.

If we think the new language is going to be particularly disruptive then we might want a transition period where it is available before making it the default — I really have no objection to this at all in general.

I will just suggest that we might want to enable these defaults quite aggressively — and I say this having been bitten by GHC2021 myself. We are committed to breaking stuff — is there much to be gained by delaying. Is it not going to delay take-up? It makes

...

...

...

whole process more complicated.

Chris

...

On 15 Feb 2024, at 16:08, Simon Peyton Jones

simon.peytonjones@gmail.com>>

...

...

wrote:

I'm not understanding your point, Chris.

I think we are planning to increasingly encourage people to specify an explicit language edition for everything. (Indeed there is discussion of an on-by-default warning that complains

if

...

you don't.) For these users, the "default language edition" is irrelevant.

So the only issue is people who don't specify a language edition at all. Changing the default language edition risks breaking their code. Why would we do that? What compelling reason is

...

...

...

...

for breaking code that we don't have to break?

For the short term,

* GHC2024 is particularly likely to break code * We have not yet educated our users to use explicit language editions

So making GHC2024 be the default language for GHC 9.10 seems (to me) to lead to entirely-unnecessary breakage, with no compelling reason to do so.

Simon

On Thu, 15 Feb 2024 at 13:21, Chris Dornan <

chris@chrisdornan.com

...

mailto:chris@chrisdornan.com> wrote:

I have been a strongly in favour of minimising surprises

but I

...

mildly resistant to this proposal.

After GHC2021 broke my code quite severly (though PolyKinds) there was an initial adjustment phase but I quickly got used to specifying the exact language I want to use everywhere. Indeed the propensity for GHCi to pick up the new breakage caused some surprises but I quickly adjusted when I realised what was going on.

The point is not that change is bad but change that is difficult to anticipate and control is bad.

I now see the GHC adoption of the new default languages,

On 19/02/2024 21:34, Eric Seidel wrote: this the there that

...

...

...

...

can very selectively break things when needed, as a

fantastic

...

development. It allows us to roll out changes in a very controlled way where at synchronisation points that are easy to understand and where developers retain control. This strikes me as a really great sweet spot for Haskell.

If we make this scheme more complicated by making some the tools adopt languages on different schedules then it risks creating confusion. Folks that want to tie down advanced features strike me as just the kind that should find it easy to fill out the appropriate settings in configuration files.

So I say lets get this rolled out ASAP (as Adam says) but

roll

...

it out consistently everywhere.

Chris

> On 15 Feb 2024, at 09:15, Simon Peyton Jones > mailto:simon.peytonjones@gmail.com> wrote: > > I'm ok with this proposal. The whole concept of a default > language seems a bit flaky to me, if we are going to start > warning any time someone doesn't explicitly specify an > explicit addition. While this is settling down, causing > minimum disruption is good. > > Simon > > On Thu, 15 Feb 2024 at 08:50, Adam Gundry > mailto:adam@well-typed.com> wrote: > > Dear committee, > > In #632, I propose amending the GHC2024 proposal to > specify that the > default language used by ghc/ghci when run directly

will

...

> remain GHC2021 > for now, since changing to GHC2024 is not backwards > compatible. (This > does not affect Cabal packages either way, since Cabal > specifies its own > default.) > > https://github.com/ghc-proposals/ghc-proposals/pull/632 > < https://github.com/ghc-proposals/ghc-proposals/pull/632> > > https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals... < https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals...

...

...

...

> > On the discussion thread, some people expressed a > preference that GHC > should default to the latest language edition anyway. > There is also > Richard's suggestion of wider changes of approach in > #636. However, > given that the GHC 9.10 fork date is fast approaching, > introducing > GHC2024 but not making it the default seems like the best > short-term > solution to me. We can always reassess our approach to > this for future > releases as part of the wider discussion. > > If you object to the proposed approach, please speak up > ASAP. Otherwise > I plan to merge in a week or so. > > Cheers, > > Adam

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

_______________________________________________ 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 Director, Research at https://moduscreate.com and https://tweag.io.

OK, well it clarifies the conversation if the question of a "default language edition" is basically just "what you get if you type 'ghci'". (The expectation being that every Foo.hs file will, one way or another, have an explicitly-specified language edition, so that it continues to work into the future.) Very well: perhaps - The GHCi REPL does the latest stable language edition (and could as you say even put that in the prompt) - All other uses of GHC (compiling a Foo.hs module) expect an explicitly-specified language edition, but use GHC2021 (or even Haskell 98!), and emit a warning to say so, if there none. Essentially we'd be encouraging users to start every Foo.hs with {-# LANGUAGE GHC2024 #-}, which makes the file admirably self-describing. I'm playing devil's advocate a bit here. But I used to think that having a default language edition was obvious, but I have come to realize that it isn't. Simon On Fri, 22 Mar 2024 at 08:20, Adam Gundry wrote:

On 21/03/2024 10:08, Simon Peyton Jones wrote:

...

It's hard to answer this without addressing the following question

* Do we want to actively encourage Haskell users to specify a language edition for every module (via a LANGUAGE pragma, cabal file, or command line option)?

I think we should thus encourage them. Because that greatly increases the chances that if the module compiles with GHC(X) then it'll compile with GHC(X+k).

We certainly should encourage them to specify a language edition for every module that will last for any length of time. But that still leaves quick one-off uses, either just firing up ghci, or writing a throwaway module. And there it's less obvious how active our encouragement should be.

...

If they do this, then the "default language edition" barely matters.

Indeed, I want to question the merit of having a "default language edition" at all. Suppose the default language edition was GHC2021 forever. All by itself that would encourage the use of an explicit language edition, to get hold a coherent bundle of extensions beyond GHC2021. We might not need to do any more than that.

The downside of this is that simply typing "ghci" will give the user a suboptimal experience (at least if we assume that future GHC20xx revisions will be better than GHC2021). So we potentially end up in a situation where expert users have learned to use "ghci -XGHC2035" but beginners use "ghci" and encounter unexpected papercuts.

In the extremely long term, perhaps we won't want to support GHC2021 forever, but if we don't have a story about evolving the default language, we are stuck. I think we are better off having a clearly identified default language per compiler version, but making users aware of when they are relying on that default.

Side thought: maybe "ghci" should print the language edition in use as part of the initial prompt, at least where the default was not overridden?

Adam

...

On Thu, 21 Mar 2024 at 09:08, Adam Gundry mailto:adam@well-typed.com> wrote:

Apologies for letting this thread linger.

The current de facto situation is that GHC 9.10 will ship with GHC2024 available but not enabled by default. (Given the timing, it did not seem feasible to change the default, and but leaving GHC2024 out of the release entirely would seem unnecessary.)

Several people have expressed the opinion that we should actively plan to switch the default, to benefit one-off use (especially in ghci), rather than simply leaving GHC2021 as the default indefinitely. So the question is what level of messaging is appropriate before that happens. I can see a few options, none of which are entirely satisfying:

* Mention in the release notes (done for 9.10, and easily done in the next release).

* Add an off-by-default warning about failure to specify a language edition (maybe in -Wall or -Wcompat). Unclear this benefits many people because if they aren't specifying a language edition or reading the release notes, they may well not be enabling non-default warnings either.

* Enable the warning about failure to specify a language edition by default. A bit noisy for ad hoc use.

* Add a warning where NoMonoLocalBinds is used and changing to MonoLocalBinds would break the program (since this is the most likely source of breakage in practice). This warning could be enabled by default if no language edition is specified. Nice for users, but probably quite a bit of implementation overhead, so unclear if it would be implemented.

* Wait for a super-major release (e.g. the 10.x series) before changing the default language. Not clear when this will be.

Any other options? Opinions?

Adam

On 19/02/2024 21:34, Eric Seidel wrote: > It seems to me that this particular proposal could make sense > tactically, but I agree with Chris and Arnaud that it feels > like the wrong thing strategically. > > I don't see us getting away from a notion of a "default language". > GCC/Clang similarly implement many C/C++ standards and let users > choose, but still define a default standard per compiler version. > And this default changes across compiler releases. Forcing even > adhoc ghc[i] sessions to specify a language standard feels > excessive. > > Thus, we need *some* cadence for updating the default language. > It could be that GHC 9.10 is too soon to make that change, but > we should commit to making the change at some point, with proper > messaging. > > Eric > > On Fri, Feb 16, 2024, at 03:08, Adam Gundry wrote: >> Thanks everyone for sharing your thoughts. >> >> I would point out that this is not just about "the handful of people >> that have ghci scripts" but rather anyone compiling modules with ghc >> directly (not using Cabal). Were it about ghci alone, I agree that the >> latest language edition would be preferable. But it seems likely to be a >> larger class, e.g. including educators teaching Haskell, and users with >> small programs where they have not created a Cabal package. >> >> Adam >> >> >> On 16/02/2024 08:36, Arnaud Spiwack wrote: >>> (I won't be able to follow this conversation as I'll be on holiday for >>> the next week so dropping my thoughts a little unstructured) >>> >>> I'm not keen on giving people gratuitous work. I think staging making >>> GHC2024 the default borders on gratuitous work (because I'm not >>> convinced that the transition period will achieve anything, but on the >>> other hand, it gives us a little bit of time to warn people). The idea >>> that we will want to make a decision for each edition in the future >>> regarding whether it's to be the default is definitely gratuitous work >>> (I can be convinced otherwise, of course: this is my current train of >>> thoughts). >>> Generally speaking, all cabal projects have a fixed `default-language` >>> (which, we learnt, is Haskell98 if omitted). So really we're doing this >>> for the handful of people that have ghci scripts. And we're making >>> everybody else's life worse (because ghci is worse). I'm, obviously, a >>> strong believer in the power of defaults. >>> >>> So, anyway, without having had much time to think about this: maybe ok >>> for staging GHC2024 in particular, just this once. I think it's a bad >>> idea, but not a hill I'll die on. The rest of the proposal I'm rather >>> opposed to. >>> >>> On Thu, 15 Feb 2024 at 20:51, Chris Dornan mailto:chris@chrisdornan.com >>> mailto:chris@chrisdornan.com>> wrote: >>> >>> Sorry, I misunderstood the proposal — for some reason I thought we >>> were going to delay the default for ghci. >>> >>> If we think the new language is going to be particularly disruptive >>> then we might want a transition period where it is available before >>> making it the default — I really have no objection to this at all in >>> general. >>> >>> I will just suggest that we might want to enable these defaults >>> quite aggressively — and I say this having been bitten by GHC2021 >>> myself. We are committed to breaking stuff — is there much to be >>> gained by delaying. Is it not going to delay take-up? It makes the >>> whole process more complicated. >>> >>> Chris >>> >>> >>>> On 15 Feb 2024, at 16:08, Simon Peyton Jones >>>> mailto:simon.peytonjones@gmail.com mailto:simon.peytonjones@gmail.com>> >>>> wrote: >>>> >>>> I'm not understanding your point, Chris. >>>> >>>> I think we are planning to increasingly encourage people to >>>> specify an explicit language edition for everything. (Indeed >>>> there is discussion of an on-by-default warning that complains if >>>> you don't.) For these users, the "default language edition" is >>>> irrelevant. >>>> >>>> So the only issue is people who don't specify a language edition >>>> at all. Changing the default language edition risks breaking >>>> their code. Why would we do that? What compelling reason is there >>>> for breaking code that we don't have to break? >>>> >>>> For the short term, >>>> >>>> * GHC2024 is particularly likely to break code >>>> * We have not yet educated our users to use explicit language >>>> editions >>>> >>>> So making GHC2024 be the default language for GHC 9.10 seems (to >>>> me) to lead to entirely-unnecessary breakage, with no compelling >>>> reason to do so. >>>> >>>> Simon >>>> >>>> On Thu, 15 Feb 2024 at 13:21, Chris Dornan mailto:chris@chrisdornan.com >>>> mailto:chris@chrisdornan.com>> wrote: >>>> >>>> I have been a strongly in favour of minimising surprises but I >>>> mildly resistant to this proposal. >>>> >>>> After GHC2021 broke my code quite severly (though PolyKinds) >>>> there was an initial adjustment phase but I quickly got used >>>> to specifying the exact language I want to use everywhere. >>>> Indeed the propensity for GHCi to pick up the new breakage >>>> caused some surprises but I quickly adjusted when I realised >>>> what was going on. >>>> >>>> The point is not that change is bad but change that is >>>> difficult to anticipate and control is bad. >>>> >>>> I now see the GHC adoption of the new default languages, that >>>> can very selectively break things when needed, as a fantastic >>>> development. It allows us to roll out changes in a very >>>> controlled way where at synchronisation points that are easy >>>> to understand and where developers retain control. This >>>> strikes me as a really great sweet spot for Haskell. >>>> >>>> If we make this scheme more complicated by making some the >>>> tools adopt languages on different schedules then it risks >>>> creating confusion. Folks that want to tie down advanced >>>> features strike me as just the kind that should find it easy >>>> to fill out the appropriate settings in configuration files. >>>> >>>> So I say lets get this rolled out ASAP (as Adam says) but roll >>>> it out consistently everywhere. >>>> >>>> Chris >>>> >>>> >>>>> On 15 Feb 2024, at 09:15, Simon Peyton Jones >>>>> mailto:simon.peytonjones@gmail.com >>>>> mailto:simon.peytonjones@gmail.com>> wrote: >>>>> >>>>> I'm ok with this proposal. The whole concept of a default >>>>> language seems a bit flaky to me, if we are going to start >>>>> warning any time someone doesn't explicitly specify an >>>>> explicit addition. While this is settling down, causing >>>>> minimum disruption is good. >>>>> >>>>> Simon >>>>> >>>>> On Thu, 15 Feb 2024 at 08:50, Adam Gundry >>>>> mailto:adam@well-typed.com mailto:adam@well-typed.com>> wrote: >>>>> >>>>> Dear committee, >>>>> >>>>> In #632, I propose amending the GHC2024 proposal to >>>>> specify that the >>>>> default language used by ghc/ghci when run directly will >>>>> remain GHC2021 >>>>> for now, since changing to GHC2024 is not backwards >>>>> compatible. (This >>>>> does not affect Cabal packages either way, since Cabal >>>>> specifies its own >>>>> default.) >>>>> >>>>> https://github.com/ghc-proposals/ghc-proposals/pull/632 https://github.com/ghc-proposals/ghc-proposals/pull/632 >>>>> <https://github.com/ghc-proposals/ghc-proposals/pull/632 https://github.com/ghc-proposals/ghc-proposals/pull/632> >>>>> >>>>>

https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals... < https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0613-ghc2024.rst#introduction-of-ghc2024> < https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals... < https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals...

...

...

>>>>> >>>>> On the discussion thread, some people expressed a >>>>> preference that GHC >>>>> should default to the latest language edition anyway. >>>>> There is also >>>>> Richard's suggestion of wider changes of approach in >>>>> #636. However, >>>>> given that the GHC 9.10 fork date is fast approaching, >>>>> introducing >>>>> GHC2024 but not making it the default seems like the best >>>>> short-term >>>>> solution to me. We can always reassess our approach to >>>>> this for future >>>>> releases as part of the wider discussion. >>>>> >>>>> If you object to the proposed approach, please speak up >>>>> ASAP. Otherwise >>>>> I plan to merge in a week or so. >>>>> >>>>> Cheers, >>>>> >>>>> Adam >>

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

I also think that the notion of default-language matters. For some reason people care greatly about which is the "real" Haskell. I really want ghci to use the latest and greatest language edition. I also would prefer it to be used when calling ghc on a quick test file. If deemed necessary we can throw a warning when we fallback to a default in that case. I think it is very important that we care about breakage for the sake of the ecosystem. But the ecosystem relies on Cabal to build packages so outside of that changes have another quality. Best Malte

I'm all for people specifying the language they want at the module (or cabal level). I would expect ghci to give me the default variant for the compiler I'm using, unless I explicitly set a specific default language (e.g. if I launch ghci through cabal, then I expect it to adhere to the language set in the cabal file). On Sat, 23 Mar 2024 at 02:27, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

I really want ghci to use the latest and greatest language edition.

I think we agree about this

I also would prefer it to be used when calling ghc on a quick test file. If deemed necessary we can throw a warning when we fallback to a default in that case.

Ah, but now we are on the slippery slope. Your "quick test file" may well become a little script you use every day... and it may then suddenly stop working when you install a new GHC with a new default language edition. We don't want that! And it is completely solved by saying that we never change the default language edition for .hs modules -- if it works now it'll work in the future because we always fall back to the same language edition. (e.g Hsakell98 or GHC2021 or whatever).

In some ways Hakell98 is better: it's very stable; and it is so old that it'll encourage you to put a one-line {-# LANGUAGE GHC2024 #-} at the top of your module to make it self-describing. I love self-describing files :-)

I wonder if this debate would be better on the GitHub discussion thread? I'd love to hear from more people.

Simon

On Fri, 22 Mar 2024 at 14:42, Malte Ott wrote:

...

I also think that the notion of default-language matters. For some reason people care greatly about which is the "real" Haskell.

I really want ghci to use the latest and greatest language edition. I also would prefer it to be used when calling ghc on a quick test file. If deemed necessary we can throw a warning when we fallback to a default in that case.

I think it is very important that we care about breakage for the sake of the ecosystem. But the ecosystem relies on Cabal to build packages so outside of that changes have another quality.

Best Malte _______________________________________________ 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

I posted a summary of options to the GitHub thread to try to solicit further feedback (https://github.com/ghc-proposals/ghc-proposals/pull/632#issuecomment-2021426...). One idea I noticed rereading the thread was Gershom's suggestion (https://github.com/ghc-proposals/ghc-proposals/pull/632#issuecomment-1924318...) that we could change the default language when the compiler gets a supermajor version bump. We missed that by a release last time, as GHC 9.0 used Haskell2010 but 9.2 used GHC2021. But we could plan for the next release after GHC 9.10 to be 10.0 and use GHC2024 by default, then in three years release GHC 11.0 with GHC2027... Adam On 25/03/2024 09:30, Simon Marlow wrote:

On Fri, 22 Mar 2024 at 18:27, Simon Peyton Jones mailto:simon.peytonjones@gmail.com> wrote:

I really want ghci to use the latest and greatest language edition.

I think we agree about this

I also would prefer it to be used when calling ghc on a quick test file. If deemed necessary we can throw a warning when we fallback to a default in that case.

Ah, but now we are on the slippery slope.  Your "quick test file" may well become a little script you use every day... and it may then suddenly stop working when you install a new GHC with a new default language edition.  We don't want that!  And it is completely solved by saying that we never change the default language edition for .hs modules -- if it works now it'll work in the future because we always fall back to the same language edition. (e.g Hsakell98 or GHC2021 or whatever).

In some ways Hakell98 is better: it's very stable; and it is so old that it'll encourage you to put a one-line {-# LANGUAGE GHC2024 #-} at the top of your module to make it self-describing.   I love self-describing files :-)

I can think of a couple of reasons not to fix the default language permanently:

* Eventually we'll want to remove support for Haskell98, GHC2021 etc. because supporting old versions of the language gets harder over time. The Fortified Language Editions proposal requires 3 years of support only. (indeed Haskell98 is already not really Haskell98, because the definition of Monad has changed for example) * Other languages don't do it this way, e.g. with gcc/g++ you get some recent version of C/C++ by default.

Cheers Simon

I wonder if this debate would be better on the GitHub discussion thread?  I'd love to hear from more people.

Simon

On Fri, 22 Mar 2024 at 14:42, Malte Ott mailto:malte.ott@maralorn.de> wrote:

I also think that the notion of default-language matters. For some reason people care greatly about which is the "real" Haskell.

I really want ghci to use the latest and greatest language edition. I also would prefer it to be used when calling ghc on a quick test file. If deemed necessary we can throw a warning when we fallback to a default in that case.

I think it is very important that we care about breakage for the sake of the ecosystem. But the ecosystem relies on Cabal to build packages so outside of that changes have another quality.

Best Malte _______________________________________________

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

Apologies for the delay in following up on this. It seems there is a general sentiment that we should bump the default to GHC2024 in a future release. I'm planning to revise the amendment to reflect this, but I've been lacking cycles to do so, thus I've moved the PR to "needs revision" status for now. Adam On 22/03/2024 15:42, Simon Marlow wrote:

I'm totally fine with bumping the default to GHC2024. Indeed that seems the least surprising behaviour, because "the latest supported by the compiler" is predictable and you don't have to look in the user guide to find out whether the default was bumped or not.

Adding a warning for ad-hoc use would be too annoying IMO.

Cheers Simon

On Thu, 21 Mar 2024 at 09:08, Adam Gundry mailto:adam@well-typed.com> wrote:

Apologies for letting this thread linger.

The current de facto situation is that GHC 9.10 will ship with GHC2024 available but not enabled by default. (Given the timing, it did not seem feasible to change the default, and but leaving GHC2024 out of the release entirely would seem unnecessary.)

Several people have expressed the opinion that we should actively plan to switch the default, to benefit one-off use (especially in ghci), rather than simply leaving GHC2021 as the default indefinitely. So the question is what level of messaging is appropriate before that happens. I can see a few options, none of which are entirely satisfying:

  * Mention in the release notes (done for 9.10, and easily done in the next release).

  * Add an off-by-default warning about failure to specify a language edition (maybe in -Wall or -Wcompat). Unclear this benefits many people because if they aren't specifying a language edition or reading the release notes, they may well not be enabling non-default warnings either.

  * Enable the warning about failure to specify a language edition by default. A bit noisy for ad hoc use.

  * Add a warning where NoMonoLocalBinds is used and changing to MonoLocalBinds would break the program (since this is the most likely source of breakage in practice). This warning could be enabled by default if no language edition is specified. Nice for users, but probably quite a bit of implementation overhead, so unclear if it would be implemented.

  * Wait for a super-major release (e.g. the 10.x series) before changing the default language. Not clear when this will be.

Any other options? Opinions?

Adam

On 19/02/2024 21:34, Eric Seidel wrote: > It seems to me that this particular proposal could make sense > tactically, but I agree with Chris and Arnaud that it feels > like the wrong thing strategically. > > I don't see us getting away from a notion of a "default language". > GCC/Clang similarly implement many C/C++ standards and let users > choose, but still define a default standard per compiler version. > And this default changes across compiler releases. Forcing even > adhoc ghc[i] sessions to specify a language standard feels > excessive. > > Thus, we need *some* cadence for updating the default language. > It could be that GHC 9.10 is too soon to make that change, but > we should commit to making the change at some point, with proper > messaging. > > Eric > > On Fri, Feb 16, 2024, at 03:08, Adam Gundry wrote: >> Thanks everyone for sharing your thoughts. >> >> I would point out that this is not just about "the handful of people >> that have ghci scripts" but rather anyone compiling modules with ghc >> directly (not using Cabal). Were it about ghci alone, I agree that the >> latest language edition would be preferable. But it seems likely to be a >> larger class, e.g. including educators teaching Haskell, and users with >> small programs where they have not created a Cabal package. >> >> Adam >> >> >> On 16/02/2024 08:36, Arnaud Spiwack wrote: >>> (I won't be able to follow this conversation as I'll be on holiday for >>> the next week so dropping my thoughts a little unstructured) >>> >>> I'm not keen on giving people gratuitous work. I think staging making >>> GHC2024 the default borders on gratuitous work (because I'm not >>> convinced that the transition period will achieve anything, but on the >>> other hand, it gives us a little bit of time to warn people). The idea >>> that we will want to make a decision for each edition in the future >>> regarding whether it's to be the default is definitely gratuitous work >>> (I can be convinced otherwise, of course: this is my current train of >>> thoughts). >>> Generally speaking, all cabal projects have a fixed `default-language` >>> (which, we learnt, is Haskell98 if omitted). So really we're doing this >>> for the handful of people that have ghci scripts. And we're making >>> everybody else's life worse (because ghci is worse). I'm, obviously, a >>> strong believer in the power of defaults. >>> >>> So, anyway, without having had much time to think about this: maybe ok >>> for staging GHC2024 in particular, just this once. I think it's a bad >>> idea, but not a hill I'll die on. The rest of the proposal I'm rather >>> opposed to. >>> >>> On Thu, 15 Feb 2024 at 20:51, Chris Dornan mailto:chris@chrisdornan.com >>> mailto:chris@chrisdornan.com>> wrote: >>> >>>      Sorry, I misunderstood the proposal — for some reason I thought we >>>      were going to delay the default for ghci. >>> >>>      If we think the new language is going to be particularly disruptive >>>      then we might want a transition period where it is available before >>>      making it the default — I really have no objection to this at all in >>>      general. >>> >>>      I will just suggest that we might want to enable these defaults >>>      quite aggressively — and I say this having been bitten by GHC2021 >>>      myself. We are committed to breaking stuff — is there much to be >>>      gained by delaying. Is it not going to delay take-up? It makes the >>>      whole process more complicated. >>> >>>      Chris >>> >>> >>>>      On 15 Feb 2024, at 16:08, Simon Peyton Jones >>>>      mailto:simon.peytonjones@gmail.com mailto:simon.peytonjones@gmail.com>> >>>>      wrote: >>>> >>>>      I'm not understanding  your point, Chris. >>>> >>>>      I think we are planning to increasingly encourage people to >>>>      specify an explicit language edition for everything.  (Indeed >>>>      there is discussion of an on-by-default warning that complains if >>>>      you don't.)  For these users, the "default language edition" is >>>>      irrelevant. >>>> >>>>      So the only issue is people who don't specify a language edition >>>>      at all.   Changing the default language edition risks breaking >>>>      their code.  Why would we do that? What compelling reason is there >>>>      for breaking code that we don't have to break? >>>> >>>>      For the short term, >>>> >>>>        * GHC2024 is particularly likely to break code >>>>        * We have not yet educated our users to use explicit language >>>>          editions >>>> >>>>      So making GHC2024 be the default language for GHC 9.10 seems (to >>>>      me) to lead to entirely-unnecessary breakage, with no compelling >>>>      reason to do so. >>>> >>>>      Simon >>>> >>>>      On Thu, 15 Feb 2024 at 13:21, Chris Dornan mailto:chris@chrisdornan.com >>>>      mailto:chris@chrisdornan.com>> wrote: >>>> >>>>          I have been a strongly in favour of minimising surprises but I >>>>          mildly resistant to this proposal. >>>> >>>>          After GHC2021 broke my code quite severly (though PolyKinds) >>>>          there was an initial adjustment phase but I quickly got used >>>>          to specifying the exact language I want to use everywhere. >>>>          Indeed the propensity for GHCi to pick up the new breakage >>>>          caused some surprises but I quickly adjusted when I realised >>>>          what was going on. >>>> >>>>          The point is not that change is bad but change that is >>>>          difficult to anticipate and control is bad. >>>> >>>>          I now see the GHC adoption of the new default languages, that >>>>          can very selectively break things when needed, as a fantastic >>>>          development. It allows us to roll out changes in a very >>>>          controlled way where at synchronisation points that are easy >>>>          to understand and where developers retain control. This >>>>          strikes me as a really great sweet spot for Haskell. >>>> >>>>          If we make this scheme more complicated by making some the >>>>          tools adopt languages on different schedules then it risks >>>>          creating confusion. Folks that want to tie down advanced >>>>          features strike me as just the kind that should find it easy >>>>          to fill out the appropriate settings in configuration files. >>>> >>>>          So I say lets get this rolled out ASAP (as Adam says) but roll >>>>          it out consistently everywhere. >>>> >>>>          Chris >>>> >>>> >>>>>          On 15 Feb 2024, at 09:15, Simon Peyton Jones >>>>>          mailto:simon.peytonjones@gmail.com >>>>>          mailto:simon.peytonjones@gmail.com>> wrote: >>>>> >>>>>          I'm ok with this proposal.  The whole concept of a default >>>>>          language seems a bit flaky to me, if we are going to start >>>>>          warning any time someone doesn't explicitly specify an >>>>>          explicit addition.  While this is settling down, causing >>>>>          minimum disruption is good. >>>>> >>>>>          Simon >>>>> >>>>>          On Thu, 15 Feb 2024 at 08:50, Adam Gundry >>>>>          mailto:adam@well-typed.com mailto:adam@well-typed.com>> wrote: >>>>> >>>>>              Dear committee, >>>>> >>>>>              In #632, I propose amending the GHC2024 proposal to >>>>>              specify that the >>>>>              default language used by ghc/ghci when run directly will >>>>>              remain GHC2021 >>>>>              for now, since changing to GHC2024 is not backwards >>>>>              compatible. (This >>>>>              does not affect Cabal packages either way, since Cabal >>>>>              specifies its own >>>>>              default.) >>>>> >>>>> https://github.com/ghc-proposals/ghc-proposals/pull/632 https://github.com/ghc-proposals/ghc-proposals/pull/632 >>>>> <https://github.com/ghc-proposals/ghc-proposals/pull/632 https://github.com/ghc-proposals/ghc-proposals/pull/632> >>>>> >>>>> https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals... https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals... <https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals... https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals...> >>>>> >>>>>              On the discussion thread, some people expressed a >>>>>              preference that GHC >>>>>              should default to the latest language edition anyway. >>>>>              There is also >>>>>              Richard's suggestion of wider changes of approach in >>>>>              #636. However, >>>>>              given that the GHC 9.10 fork date is fast approaching, >>>>>              introducing >>>>>              GHC2024 but not making it the default seems like the best >>>>>              short-term >>>>>              solution to me. We can always reassess our approach to >>>>>              this for future >>>>>              releases as part of the wider discussion. >>>>> >>>>>              If you object to the proposed approach, please speak up >>>>>              ASAP. Otherwise >>>>>              I plan to merge in a week or so. >>>>> >>>>>              Cheers, >>>>> >>>>>              Adam >>

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