[ghc-steering-committee] #632: Phased introduction of GHC2024

[Chris Dornan]

Sorry, I misunderstood the proposal — for some reason I thought we were going to delay the default for ghci.

If we think the new language is going to be particularly disruptive then we might want a transition period where it is available before making it the default — I really have no objection to this at all in general.

I will just suggest that we might want to enable these defaults quite aggressively — and I say this having been bitten by GHC2021 myself. We are committed to breaking stuff — is there much to be gained by delaying. Is it not going to delay take-up? It makes the whole process more complicated.

Chris
 

> On 15 Feb 2024, at 16:08, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
> I'm not understanding  your point, Chris.
> 
> I think we are planning to increasingly encourage people to specify an explicit language edition for everything.  (Indeed there is discussion of an on-by-default warning that complains if you don't.)  For these users, the "default language edition" is irrelevant.
> 
> So the only issue is people who don't specify a language edition at all.   Changing the default language edition risks breaking their code.  Why would we do that? What compelling reason is there for breaking code that we don't have to break?
> 
> For the short term,
> GHC2024 is particularly likely to break code
> We have not yet educated our users to use explicit language editions
> So making GHC2024 be the default language for GHC 9.10 seems (to me) to lead to entirely-unnecessary breakage, with no compelling reason to do so.
> 
> Simon
> 
> On Thu, 15 Feb 2024 at 13:21, Chris Dornan <chris at chrisdornan.com <mailto:chris at chrisdornan.com>> wrote:
>> I have been a strongly in favour of minimising surprises but I mildly resistant to this proposal.
>> 
>> After GHC2021 broke my code quite severly (though PolyKinds) there was an initial adjustment phase but I quickly got used to specifying the exact language I want to use everywhere. Indeed the propensity for GHCi to pick up the new breakage caused some surprises but I quickly adjusted when I realised what was going on.
>> 
>> The point is not that change is bad but change that is difficult to anticipate and control is bad. 
>> 
>> I now see the GHC adoption of the new default languages, that can very selectively break things when needed, as a fantastic development. It allows us to roll out changes in a very controlled way where at synchronisation points that are easy to understand and where developers retain control. This strikes me as a really great sweet spot for Haskell.
>> 
>> If we make this scheme more complicated by making some the tools adopt languages on different schedules then it risks creating confusion. Folks that want to tie down advanced features strike me as just the kind that should find it easy to fill out the appropriate settings in configuration files.
>> 
>> So I say lets get this rolled out ASAP (as Adam says) but roll it out consistently everywhere.
>> 
>> Chris
>> 
>> 
>>> On 15 Feb 2024, at 09:15, Simon Peyton Jones <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
>>> 
>>> I'm ok with this proposal.  The whole concept of a default language seems a bit flaky to me, if we are going to start warning any time someone doesn't explicitly specify an explicit addition.  While this is settling down, causing minimum disruption is good.
>>> 
>>> Simon
>>> 
>>> On Thu, 15 Feb 2024 at 08:50, Adam Gundry <adam at well-typed.com <mailto:adam at well-typed.com>> wrote:
>>>> Dear committee,
>>>> 
>>>> In #632, I propose amending the GHC2024 proposal to specify that the 
>>>> default language used by ghc/ghci when run directly will remain GHC2021 
>>>> for now, since changing to GHC2024 is not backwards compatible. (This 
>>>> does not affect Cabal packages either way, since Cabal specifies its own 
>>>> default.)
>>>> 
>>>> https://github.com/ghc-proposals/ghc-proposals/pull/632
>>>> 
>>>> https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0613-ghc2024.rst#introduction-of-ghc2024
>>>> 
>>>> On the discussion thread, some people expressed a preference that GHC 
>>>> should default to the latest language edition anyway. There is also 
>>>> Richard's suggestion of wider changes of approach in #636. However, 
>>>> given that the GHC 9.10 fork date is fast approaching, introducing 
>>>> GHC2024 but not making it the default seems like the best short-term 
>>>> solution to me. We can always reassess our approach to this for future 
>>>> releases as part of the wider discussion.
>>>> 
>>>> If you object to the proposed approach, please speak up ASAP. Otherwise 
>>>> I plan to merge in a week or so.
>>>> 
>>>> Cheers,
>>>> 
>>>> Adam
>>>> 
>>>> 
>>>> -- 
>>>> Adam Gundry, Haskell Consultant
>>>> Well-Typed LLP, https://www.well-typed.com/
>>>> 
>>>> Registered in England & Wales, OC335890
>>>> 27 Old Gloucester Street, London WC1N 3AX, England
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240215/080f9b66/attachment-0001.html>