<div dir="ltr"><div>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.</div><div><br></div><div>Adding a warning for ad-hoc use would be too annoying IMO. </div><div><br></div><div>Cheers</div><div>Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 21 Mar 2024 at 09:08, 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">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 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 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 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 that the<br>
>> latest language edition would be preferable. But it seems likely to be a<br>
>> larger class, e.g. including educators teaching Haskell, and 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 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 making<br>
>>> GHC2024 the default borders on gratuitous work (because I'm not<br>
>>> convinced that the transition period will achieve anything, but on the<br>
>>> other hand, it gives us a little bit of time to warn people). 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 gratuitous work<br>
>>> (I can be convinced otherwise, of course: this is my current train of<br>
>>> thoughts).<br>
>>> Generally speaking, all cabal projects have a fixed `default-language`<br>
>>> (which, we learnt, is Haskell98 if omitted). So really we're 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, obviously, a<br>
>>> strong believer in the power of defaults.<br>
>>><br>
>>> So, anyway, without having had much time to think about this: maybe ok<br>
>>> for staging GHC2024 in particular, just this once. I think it's a bad<br>
>>> idea, but not a hill I'll die on. The rest of the proposal I'm rather<br>
>>> opposed to.<br>
>>><br>
>>> On Thu, 15 Feb 2024 at 20:51, Chris Dornan <<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>
>>> Sorry, I misunderstood the proposal — for some reason I thought we<br>
>>> were going to delay the default for ghci.<br>
>>><br>
>>> If we think the new language is going to be particularly disruptive<br>
>>> then we might want a transition period where it is available before<br>
>>> making it the default — I really have no objection to this at all in<br>
>>> general.<br>
>>><br>
>>> I will just suggest that we might want to enable these defaults<br>
>>> quite aggressively — and I say this having been bitten by GHC2021<br>
>>> myself. We are committed to breaking stuff — is there much to be<br>
>>> gained by delaying. Is it not going to delay take-up? It 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> <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 complains if<br>
>>>> you don't.) For these users, the "default language edition" is<br>
>>>> irrelevant.<br>
>>>><br>
>>>> So the only issue is people who don't specify a language edition<br>
>>>> at all. Changing the default language edition risks breaking<br>
>>>> their code. Why would we do that? What compelling reason 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 language<br>
>>>> editions<br>
>>>><br>
>>>> So making GHC2024 be the default language for GHC 9.10 seems (to<br>
>>>> me) to lead to entirely-unnecessary breakage, with no compelling<br>
>>>> reason to do so.<br>
>>>><br>
>>>> Simon<br>
>>>><br>
>>>> On Thu, 15 Feb 2024 at 13:21, Chris Dornan <<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 surprises but I<br>
>>>> mildly resistant to this proposal.<br>
>>>><br>
>>>> After GHC2021 broke my code quite severly (though PolyKinds)<br>
>>>> there was an initial adjustment phase but I quickly got used<br>
>>>> to specifying the exact language I want to use everywhere.<br>
>>>> Indeed the propensity for GHCi to pick up the new breakage<br>
>>>> caused some surprises but I quickly adjusted when I 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 languages, that<br>
>>>> can very selectively break things when needed, as a fantastic<br>
>>>> development. It allows us to roll out changes in a very<br>
>>>> controlled way where at synchronisation points that 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 some the<br>
>>>> tools adopt languages on different schedules then it risks<br>
>>>> creating confusion. Folks that want to tie down advanced<br>
>>>> features strike me as just the kind that should find it easy<br>
>>>> to fill out the appropriate settings in configuration files.<br>
>>>><br>
>>>> So I say lets get this rolled out ASAP (as Adam says) 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>>> wrote:<br>
>>>>><br>
>>>>> I'm ok with this proposal. The whole concept of a default<br>
>>>>> language seems a bit flaky to me, if we are going to 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>>> 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 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 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/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 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 approaching,<br>
>>>>> introducing<br>
>>>>> GHC2024 but not making it the default seems like the best<br>
>>>>> short-term<br>
>>>>> solution to me. We can always reassess our approach to<br>
>>>>> this for future<br>
>>>>> releases as part of the wider discussion.<br>
>>>>><br>
>>>>> If you object to the proposed approach, please 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>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>