<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">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.)</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Very well: perhaps</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><ul><li>The GHCi REPL does the latest stable language edition (and could as you say even put that in the prompt)<br></li><li>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.</li></ul><div><br></div><div>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.<br></div><div><br></div><div>Simon<br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 22 Mar 2024 at 08:20, Adam Gundry <<a href="mailto:adam@well-typed.com">adam@well-typed.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 21/03/2024 10:08, Simon Peyton Jones wrote:<br>
> It's hard to answer this without addressing the following question<br>
> <br>
>  Â * Do we want to actively encourage Haskell users to specify a language<br>
>  Â  Â edition for every module (via a LANGUAGE pragma, cabal file, or<br>
>  Â  Â command line option)?<br>
> <br>
> I think we should thus encourage them. Because that greatly increases <br>
> the chances that if the module compiles with GHC(X) then it'll compile <br>
> with GHC(X+k).<br>
<br>
We certainly should encourage them to specify a language edition for <br>
every module that will last for any length of time. But that still <br>
leaves quick one-off uses, either just firing up ghci, or writing a <br>
throwaway module. And there it's less obvious how active our <br>
encouragement should be.<br>
<br>
<br>
> If they do this, then the "default language edition" barely matters.<br>
> <br>
> Indeed, I want to question the merit of having a "default language <br>
> edition" at all.  Suppose the default language edition was GHC2021 <br>
> forever.  All by itself that would encourage the use of an explicit <br>
> language edition, to get hold a coherent bundle of extensions beyond <br>
> GHC2021.  We might not need to do any more than that.<br>
<br>
The downside of this is that simply typing "ghci" will give the user a <br>
suboptimal experience (at least if we assume that future GHC20xx <br>
revisions will be better than GHC2021). So we potentially end up in a <br>
situation where expert users have learned to use "ghci -XGHC2035" but <br>
beginners use "ghci" and encounter unexpected papercuts.<br>
<br>
In the extremely long term, perhaps we won't want to support GHC2021 <br>
forever, but if we don't have a story about evolving the default <br>
language, we are stuck. I think we are better off having a clearly <br>
identified default language per compiler version, but making users aware <br>
of when they are relying on that default.<br>
<br>
Side thought: maybe "ghci" should print the language edition in use as <br>
part of the initial prompt, at least where the default was not overridden?<br>
<br>
Adam<br>
<br>
<br>
> On Thu, 21 Mar 2024 at 09:08, Adam Gundry <<a href="mailto:adam@well-typed.com" target="_blank">adam@well-typed.com</a> <br>
> <mailto:<a href="mailto:adam@well-typed.com" target="_blank">adam@well-typed.com</a>>> wrote:<br>
> <br>
>  Â  Â Apologies for letting this thread linger.<br>
> <br>
>  Â  Â The current de facto situation is that GHC 9.10 will ship with GHC2024<br>
>  Â  Â available but not enabled by default. (Given the timing, it did not<br>
>  Â  Â seem<br>
>  Â  Â feasible to change the default, and but leaving GHC2024 out of the<br>
>  Â  Â release entirely would seem unnecessary.)<br>
> <br>
>  Â  Â Several people have expressed the opinion that we should actively plan<br>
>  Â  Â to switch the default, to benefit one-off use (especially in ghci),<br>
>  Â  Â rather than simply leaving GHC2021 as the default indefinitely. So the<br>
>  Â  Â question is what level of messaging is appropriate before that happens.<br>
>  Â  Â I can see a few options, none of which are entirely satisfying:<br>
> <br>
>  Â  Â  Â  * Mention in the release notes (done for 9.10, and easily done in<br>
>  Â  Â the<br>
>  Â  Â next release).<br>
> <br>
>  Â  Â  Â  * Add an off-by-default warning about failure to specify a language<br>
>  Â  Â edition (maybe in -Wall or -Wcompat). Unclear this benefits many people<br>
>  Â  Â because if they aren't specifying a language edition or reading the<br>
>  Â  Â release notes, they may well not be enabling non-default warnings<br>
>  Â  Â either.<br>
> <br>
>  Â  Â  Â  * Enable the warning about failure to specify a language edition by<br>
>  Â  Â default. A bit noisy for ad hoc use.<br>
> <br>
>  Â  Â  Â  * Add a warning where NoMonoLocalBinds is used and changing to<br>
>  Â  Â MonoLocalBinds would break the program (since this is the most likely<br>
>  Â  Â source of breakage in practice). This warning could be enabled by<br>
>  Â  Â default if no language edition is specified. Nice for users, but<br>
>  Â  Â probably quite a bit of implementation overhead, so unclear if it would<br>
>  Â  Â be implemented.<br>
> <br>
>  Â  Â  Â  * Wait for a super-major release (e.g. the 10.x series) before<br>
>  Â  Â changing the default language. Not clear when this will be.<br>
> <br>
>  Â  Â Any other options? Opinions?<br>
> <br>
>  Â  Â Adam<br>
> <br>
> <br>
>  Â  Â On 19/02/2024 21:34, Eric Seidel wrote:<br>
>  Â  Â  > It seems to me that this particular proposal could make sense<br>
>  Â  Â  > tactically, but I agree with Chris and Arnaud that it feels<br>
>  Â  Â  > like the wrong thing strategically.<br>
>  Â  Â  ><br>
>  Â  Â  > I don't see us getting away from a notion of a "default language".<br>
>  Â  Â  > GCC/Clang similarly implement many C/C++ standards and let users<br>
>  Â  Â  > choose, but still define a default standard per compiler version.<br>
>  Â  Â  > And this default changes across compiler releases. Forcing even<br>
>  Â  Â  > adhoc ghc[i] sessions to specify a language standard feels<br>
>  Â  Â  > excessive.<br>
>  Â  Â  ><br>
>  Â  Â  > Thus, we need *some* cadence for updating the default language.<br>
>  Â  Â  > It could be that GHC 9.10 is too soon to make that change, but<br>
>  Â  Â  > we should commit to making the change at some point, with proper<br>
>  Â  Â  > messaging.<br>
>  Â  Â  ><br>
>  Â  Â  > Eric<br>
>  Â  Â  ><br>
>  Â  Â  > On Fri, Feb 16, 2024, at 03:08, Adam Gundry wrote:<br>
>  Â  Â  >> Thanks everyone for sharing your thoughts.<br>
>  Â  Â  >><br>
>  Â  Â  >> I would point out that this is not just about "the handful of people<br>
>  Â  Â  >> that have ghci scripts" but rather anyone compiling modules with ghc<br>
>  Â  Â  >> directly (not using Cabal). Were it about ghci alone, I agree<br>
>  Â  Â that the<br>
>  Â  Â  >> latest language edition would be preferable. But it seems likely<br>
>  Â  Â to be a<br>
>  Â  Â  >> larger class, e.g. including educators teaching Haskell, and<br>
>  Â  Â users with<br>
>  Â  Â  >> small programs where they have not created a Cabal package.<br>
>  Â  Â  >><br>
>  Â  Â  >> Adam<br>
>  Â  Â  >><br>
>  Â  Â  >><br>
>  Â  Â  >> On 16/02/2024 08:36, Arnaud Spiwack wrote:<br>
>  Â  Â  >>> (I won't be able to follow this conversation as I'll be on<br>
>  Â  Â holiday for<br>
>  Â  Â  >>> the next week so dropping my thoughts a little unstructured)<br>
>  Â  Â  >>><br>
>  Â  Â  >>> I'm not keen on giving people gratuitous work. I think staging<br>
>  Â  Â making<br>
>  Â  Â  >>> GHC2024 the default borders on gratuitous work (because I'm not<br>
>  Â  Â  >>> convinced that the transition period will achieve anything, but<br>
>  Â  Â on the<br>
>  Â  Â  >>> other hand, it gives us a little bit of time to warn people).<br>
>  Â  Â The idea<br>
>  Â  Â  >>> that we will want to make a decision for each edition in the future<br>
>  Â  Â  >>> regarding whether it's to be the default is definitely<br>
>  Â  Â gratuitous work<br>
>  Â  Â  >>> (I can be convinced otherwise, of course: this is my current<br>
>  Â  Â train of<br>
>  Â  Â  >>> thoughts).<br>
>  Â  Â  >>> Generally speaking, all cabal projects have a fixed<br>
>  Â  Â `default-language`<br>
>  Â  Â  >>> (which, we learnt, is Haskell98 if omitted). So really we're<br>
>  Â  Â doing this<br>
>  Â  Â  >>> for the handful of people that have ghci scripts. And we're making<br>
>  Â  Â  >>> everybody else's life worse (because ghci is worse). I'm,<br>
>  Â  Â obviously, a<br>
>  Â  Â  >>> strong believer in the power of defaults.<br>
>  Â  Â  >>><br>
>  Â  Â  >>> So, anyway, without having had much time to think about this:<br>
>  Â  Â maybe ok<br>
>  Â  Â  >>> for staging GHC2024 in particular, just this once. I think it's<br>
>  Â  Â a bad<br>
>  Â  Â  >>> idea, but not a hill I'll die on. The rest of the proposal I'm<br>
>  Â  Â rather<br>
>  Â  Â  >>> opposed to.<br>
>  Â  Â  >>><br>
>  Â  Â  >>> On Thu, 15 Feb 2024 at 20:51, Chris Dornan<br>
>  Â  Â <<a href="mailto:chris@chrisdornan.com" target="_blank">chris@chrisdornan.com</a> <mailto:<a href="mailto:chris@chrisdornan.com" target="_blank">chris@chrisdornan.com</a>><br>
>  Â  Â  >>> <mailto:<a href="mailto:chris@chrisdornan.com" target="_blank">chris@chrisdornan.com</a> <mailto:<a href="mailto:chris@chrisdornan.com" target="_blank">chris@chrisdornan.com</a>>>><br>
>  Â  Â wrote:<br>
>  Â  Â  >>><br>
>  Â  Â  >>>  Â  Â  Sorry, I misunderstood the proposal â€” for some reason I<br>
>  Â  Â thought we<br>
>  Â  Â  >>>  Â  Â  were going to delay the default for ghci.<br>
>  Â  Â  >>><br>
>  Â  Â  >>>  Â  Â  If we think the new language is going to be particularly<br>
>  Â  Â disruptive<br>
>  Â  Â  >>>  Â  Â  then we might want a transition period where it is<br>
>  Â  Â available before<br>
>  Â  Â  >>>  Â  Â  making it the default â€” I really have no objection to this<br>
>  Â  Â at all in<br>
>  Â  Â  >>>  Â  Â  general.<br>
>  Â  Â  >>><br>
>  Â  Â  >>>  Â  Â  I will just suggest that we might want to enable these<br>
>  Â  Â defaults<br>
>  Â  Â  >>>  Â  Â  quite aggressively â€” and I say this having been bitten by<br>
>  Â  Â GHC2021<br>
>  Â  Â  >>>  Â  Â  myself. We are committed to breaking stuff â€” is there much<br>
>  Â  Â to be<br>
>  Â  Â  >>>  Â  Â  gained by delaying. Is it not going to delay take-up? It<br>
>  Â  Â makes the<br>
>  Â  Â  >>>  Â  Â  whole process more complicated.<br>
>  Â  Â  >>><br>
>  Â  Â  >>>  Â  Â  Chris<br>
>  Â  Â  >>><br>
>  Â  Â  >>><br>
>  Â  Â  >>>>  Â  Â  On 15 Feb 2024, at 16:08, Simon Peyton Jones<br>
>  Â  Â  >>>>  Â  Â  <<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a><br>
>  Â  Â <mailto:<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a>><br>
>  Â  Â <mailto:<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a><br>
>  Â  Â <mailto:<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a>>>><br>
>  Â  Â  >>>>  Â  Â  wrote:<br>
>  Â  Â  >>>><br>
>  Â  Â  >>>>  Â  Â  I'm not understanding  your point, Chris.<br>
>  Â  Â  >>>><br>
>  Â  Â  >>>>  Â  Â  I think we are planning to increasingly encourage people to<br>
>  Â  Â  >>>>  Â  Â  specify an explicit language edition for everything.  (Indeed<br>
>  Â  Â  >>>>  Â  Â  there is discussion of an on-by-default warning that<br>
>  Â  Â complains if<br>
>  Â  Â  >>>>  Â  Â  you don't.)  For these users, the "default language<br>
>  Â  Â edition" is<br>
>  Â  Â  >>>>  Â  Â  irrelevant.<br>
>  Â  Â  >>>><br>
>  Â  Â  >>>>  Â  Â  So the only issue is people who don't specify a language<br>
>  Â  Â edition<br>
>  Â  Â  >>>>  Â  Â  at all.   Changing the default language edition risks<br>
>  Â  Â breaking<br>
>  Â  Â  >>>>  Â  Â  their code.  Why would we do that? What compelling reason<br>
>  Â  Â is there<br>
>  Â  Â  >>>>  Â  Â  for breaking code that we don't have to break?<br>
>  Â  Â  >>>><br>
>  Â  Â  >>>>  Â  Â  For the short term,<br>
>  Â  Â  >>>><br>
>  Â  Â  >>>>  Â  Â  Â  * GHC2024 is particularly likely to break code<br>
>  Â  Â  >>>>  Â  Â  Â  * We have not yet educated our users to use explicit<br>
>  Â  Â language<br>
>  Â  Â  >>>>  Â  Â  Â  Â  editions<br>
>  Â  Â  >>>><br>
>  Â  Â  >>>>  Â  Â  So making GHC2024 be the default language for GHC 9.10<br>
>  Â  Â seems (to<br>
>  Â  Â  >>>>  Â  Â  me) to lead to entirely-unnecessary breakage, with no<br>
>  Â  Â compelling<br>
>  Â  Â  >>>>  Â  Â  reason to do so.<br>
>  Â  Â  >>>><br>
>  Â  Â  >>>>  Â  Â  Simon<br>
>  Â  Â  >>>><br>
>  Â  Â  >>>>  Â  Â  On Thu, 15 Feb 2024 at 13:21, Chris Dornan<br>
>  Â  Â <<a href="mailto:chris@chrisdornan.com" target="_blank">chris@chrisdornan.com</a> <mailto:<a href="mailto:chris@chrisdornan.com" target="_blank">chris@chrisdornan.com</a>><br>
>  Â  Â  >>>>  Â  Â  <mailto:<a href="mailto:chris@chrisdornan.com" target="_blank">chris@chrisdornan.com</a><br>
>  Â  Â <mailto:<a href="mailto:chris@chrisdornan.com" target="_blank">chris@chrisdornan.com</a>>>> wrote:<br>
>  Â  Â  >>>><br>
>  Â  Â  >>>>  Â  Â  Â  Â  I have been a strongly in favour of minimising<br>
>  Â  Â surprises but I<br>
>  Â  Â  >>>>  Â  Â  Â  Â  mildly resistant to this proposal.<br>
>  Â  Â  >>>><br>
>  Â  Â  >>>>  Â  Â  Â  Â  After GHC2021 broke my code quite severly (though<br>
>  Â  Â PolyKinds)<br>
>  Â  Â  >>>>  Â  Â  Â  Â  there was an initial adjustment phase but I quickly<br>
>  Â  Â got used<br>
>  Â  Â  >>>>  Â  Â  Â  Â  to specifying the exact language I want to use<br>
>  Â  Â everywhere.<br>
>  Â  Â  >>>>  Â  Â  Â  Â  Indeed the propensity for GHCi to pick up the new<br>
>  Â  Â breakage<br>
>  Â  Â  >>>>  Â  Â  Â  Â  caused some surprises but I quickly adjusted when I<br>
>  Â  Â realised<br>
>  Â  Â  >>>>  Â  Â  Â  Â  what was going on.<br>
>  Â  Â  >>>><br>
>  Â  Â  >>>>  Â  Â  Â  Â  The point is not that change is bad but change that is<br>
>  Â  Â  >>>>  Â  Â  Â  Â  difficult to anticipate and control is bad.<br>
>  Â  Â  >>>><br>
>  Â  Â  >>>>  Â  Â  Â  Â  I now see the GHC adoption of the new default<br>
>  Â  Â languages, that<br>
>  Â  Â  >>>>  Â  Â  Â  Â  can very selectively break things when needed, as a<br>
>  Â  Â fantastic<br>
>  Â  Â  >>>>  Â  Â  Â  Â  development. It allows us to roll out changes in a very<br>
>  Â  Â  >>>>  Â  Â  Â  Â  controlled way where at synchronisation points that<br>
>  Â  Â are easy<br>
>  Â  Â  >>>>  Â  Â  Â  Â  to understand and where developers retain control. This<br>
>  Â  Â  >>>>  Â  Â  Â  Â  strikes me as a really great sweet spot for Haskell.<br>
>  Â  Â  >>>><br>
>  Â  Â  >>>>  Â  Â  Â  Â  If we make this scheme more complicated by making<br>
>  Â  Â some the<br>
>  Â  Â  >>>>  Â  Â  Â  Â  tools adopt languages on different schedules then it<br>
>  Â  Â risks<br>
>  Â  Â  >>>>  Â  Â  Â  Â  creating confusion. Folks that want to tie down advanced<br>
>  Â  Â  >>>>  Â  Â  Â  Â  features strike me as just the kind that should find<br>
>  Â  Â it easy<br>
>  Â  Â  >>>>  Â  Â  Â  Â  to fill out the appropriate settings in configuration<br>
>  Â  Â files.<br>
>  Â  Â  >>>><br>
>  Â  Â  >>>>  Â  Â  Â  Â  So I say lets get this rolled out ASAP (as Adam says)<br>
>  Â  Â but roll<br>
>  Â  Â  >>>>  Â  Â  Â  Â  it out consistently everywhere.<br>
>  Â  Â  >>>><br>
>  Â  Â  >>>>  Â  Â  Â  Â  Chris<br>
>  Â  Â  >>>><br>
>  Â  Â  >>>><br>
>  Â  Â  >>>>>  Â  Â  Â  Â  On 15 Feb 2024, at 09:15, Simon Peyton Jones<br>
>  Â  Â  >>>>>  Â  Â  Â  Â  <<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a><br>
>  Â  Â <mailto:<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a>><br>
>  Â  Â  >>>>>  Â  Â  Â  Â  <mailto:<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a><br>
>  Â  Â <mailto:<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a>>>> wrote:<br>
>  Â  Â  >>>>><br>
>  Â  Â  >>>>>  Â  Â  Â  Â  I'm ok with this proposal.  The whole concept of a<br>
>  Â  Â default<br>
>  Â  Â  >>>>>  Â  Â  Â  Â  language seems a bit flaky to me, if we are going to<br>
>  Â  Â start<br>
>  Â  Â  >>>>>  Â  Â  Â  Â  warning any time someone doesn't explicitly specify an<br>
>  Â  Â  >>>>>  Â  Â  Â  Â  explicit addition.  While this is settling down, causing<br>
>  Â  Â  >>>>>  Â  Â  Â  Â  minimum disruption is good.<br>
>  Â  Â  >>>>><br>
>  Â  Â  >>>>>  Â  Â  Â  Â  Simon<br>
>  Â  Â  >>>>><br>
>  Â  Â  >>>>>  Â  Â  Â  Â  On Thu, 15 Feb 2024 at 08:50, Adam Gundry<br>
>  Â  Â  >>>>>  Â  Â  Â  Â  <<a href="mailto:adam@well-typed.com" target="_blank">adam@well-typed.com</a> <mailto:<a href="mailto:adam@well-typed.com" target="_blank">adam@well-typed.com</a>><br>
>  Â  Â <mailto:<a href="mailto:adam@well-typed.com" target="_blank">adam@well-typed.com</a> <mailto:<a href="mailto:adam@well-typed.com" target="_blank">adam@well-typed.com</a>>>> wrote:<br>
>  Â  Â  >>>>><br>
>  Â  Â  >>>>>  Â  Â  Â  Â  Â  Â  Dear committee,<br>
>  Â  Â  >>>>><br>
>  Â  Â  >>>>>  Â  Â  Â  Â  Â  Â  In #632, I propose amending the GHC2024 proposal to<br>
>  Â  Â  >>>>>  Â  Â  Â  Â  Â  Â  specify that the<br>
>  Â  Â  >>>>>  Â  Â  Â  Â  Â  Â  default language used by ghc/ghci when run<br>
>  Â  Â directly will<br>
>  Â  Â  >>>>>  Â  Â  Â  Â  Â  Â  remain GHC2021<br>
>  Â  Â  >>>>>  Â  Â  Â  Â  Â  Â  for now, since changing to GHC2024 is not backwards<br>
>  Â  Â  >>>>>  Â  Â  Â  Â  Â  Â  compatible. (This<br>
>  Â  Â  >>>>>  Â  Â  Â  Â  Â  Â  does not affect Cabal packages either way, since<br>
>  Â  Â Cabal<br>
>  Â  Â  >>>>>  Â  Â  Â  Â  Â  Â  specifies its own<br>
>  Â  Â  >>>>>  Â  Â  Â  Â  Â  Â  default.)<br>
>  Â  Â  >>>>><br>
>  Â  Â  >>>>> <a href="https://github.com/ghc-proposals/ghc-proposals/pull/632" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/632</a><br>
>  Â  Â <<a href="https://github.com/ghc-proposals/ghc-proposals/pull/632" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/632</a>><br>
>  Â  Â  >>>>>  Â  Â  Â  Â  Â  Â <br>
>  Â  Â <<a href="https://github.com/ghc-proposals/ghc-proposals/pull/632" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/632</a><br>
>  Â  Â <<a href="https://github.com/ghc-proposals/ghc-proposals/pull/632" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/632</a>>><br>
>  Â  Â  >>>>><br>
>  Â  Â  >>>>><br>
>  Â  Â <a href="https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0613-ghc2024.rst#introduction-of-ghc2024" rel="noreferrer" target="_blank">https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0613-ghc2024.rst#introduction-of-ghc2024</a> <<a href="https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0613-ghc2024.rst#introduction-of-ghc2024" rel="noreferrer" target="_blank">https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0613-ghc2024.rst#introduction-of-ghc2024</a>> <<a href="https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0613-ghc2024.rst#introduction-of-ghc2024" rel="noreferrer" target="_blank">https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0613-ghc2024.rst#introduction-of-ghc2024</a> <<a href="https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0613-ghc2024.rst#introduction-of-ghc2024" rel="noreferrer" target="_blank">https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0613-ghc2024.rst#introduction-of-ghc2024</a>>><br>
>  Â  Â  >>>>><br>
>  Â  Â  >>>>>  Â  Â  Â  Â  Â  Â  On the discussion thread, some people expressed a<br>
>  Â  Â  >>>>>  Â  Â  Â  Â  Â  Â  preference that GHC<br>
>  Â  Â  >>>>>  Â  Â  Â  Â  Â  Â  should default to the latest language edition<br>
>  Â  Â anyway.<br>
>  Â  Â  >>>>>  Â  Â  Â  Â  Â  Â  There is also<br>
>  Â  Â  >>>>>  Â  Â  Â  Â  Â  Â  Richard's suggestion of wider changes of approach in<br>
>  Â  Â  >>>>>  Â  Â  Â  Â  Â  Â  #636. However,<br>
>  Â  Â  >>>>>  Â  Â  Â  Â  Â  Â  given that the GHC 9.10 fork date is fast<br>
>  Â  Â approaching,<br>
>  Â  Â  >>>>>  Â  Â  Â  Â  Â  Â  introducing<br>
>  Â  Â  >>>>>  Â  Â  Â  Â  Â  Â  GHC2024 but not making it the default seems like<br>
>  Â  Â the best<br>
>  Â  Â  >>>>>  Â  Â  Â  Â  Â  Â  short-term<br>
>  Â  Â  >>>>>  Â  Â  Â  Â  Â  Â  solution to me. We can always reassess our<br>
>  Â  Â approach to<br>
>  Â  Â  >>>>>  Â  Â  Â  Â  Â  Â  this for future<br>
>  Â  Â  >>>>>  Â  Â  Â  Â  Â  Â  releases as part of the wider discussion.<br>
>  Â  Â  >>>>><br>
>  Â  Â  >>>>>  Â  Â  Â  Â  Â  Â  If you object to the proposed approach, please<br>
>  Â  Â speak up<br>
>  Â  Â  >>>>>  Â  Â  Â  Â  Â  Â  ASAP. Otherwise<br>
>  Â  Â  >>>>>  Â  Â  Â  Â  Â  Â  I plan to merge in a week or so.<br>
>  Â  Â  >>>>><br>
>  Â  Â  >>>>>  Â  Â  Â  Â  Â  Â  Cheers,<br>
>  Â  Â  >>>>><br>
>  Â  Â  >>>>>  Â  Â  Â  Â  Â  Â  Adam<br>
>  Â  Â  >><br>
> <br>
<br>
-- <br>
Adam Gundry, Haskell Consultant<br>
Well-Typed LLP, <a href="https://www.well-typed.com/" rel="noreferrer" target="_blank">https://www.well-typed.com/</a><br>
<br>
Registered in England & Wales, OC335890<br>
27 Old Gloucester Street, London WC1N 3AX, England<br>
<br>
</blockquote></div>