<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">It's hard to answer this without addressing the following question</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><ul><li>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)?</li></ul><div></div><div>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).
</div><div><br></div><div>If they do this, then the "default language edition" barely matters. <br></div><div><br></div><div></div><div>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. <br></div><div><br></div><div>Simon<br></div><div><br></div><div><br></div></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>