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

Fri Feb 16 08:36:46 UTC 2024

(I won't be able to follow this conversation as I'll be on holiday for the
next week so dropping my thoughts a little unstructured)

I'm not keen on giving people gratuitous work. I think staging making
GHC2024 the default borders on gratuitous work (because I'm not convinced
that the transition period will achieve anything, but on the other hand, it
gives us a little bit of time to warn people). The idea that we will want
to make a decision for each edition in the future regarding whether it's to
be the default is definitely gratuitous work (I can be convinced otherwise,
of course: this is my current train of thoughts).
Generally speaking, all cabal projects have a fixed `default-language`
(which, we learnt, is Haskell98 if omitted). So really we're doing this for
the handful of people that have ghci scripts. And we're making everybody
else's life worse (because ghci is worse). I'm, obviously, a strong
believer in the power of defaults.

So, anyway, without having had much time to think about this: maybe ok for
staging GHC2024 in particular, just this once. I think it's a bad idea, but
not a hill I'll die on. The rest of the proposal I'm rather opposed to.

On Thu, 15 Feb 2024 at 20:51, Chris Dornan <chris at chrisdornan.com> wrote:

> 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> 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>
>> 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> 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
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> 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
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>

-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240216/2f881ec6/attachment.html>