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