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