[ghc-steering-committee] #632: Phased introduction of GHC2024
Simon Peyton Jones
simon.peytonjones at gmail.com
Thu Mar 21 10:08:02 UTC 2024
It's hard to answer this without addressing the following question
- 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)?
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).
If they do this, then the "default language edition" barely matters.
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.
Simon
On Thu, 21 Mar 2024 at 09:08, Adam Gundry <adam at well-typed.com> wrote:
> Apologies for letting this thread linger.
>
> The current de facto situation is that GHC 9.10 will ship with GHC2024
> available but not enabled by default. (Given the timing, it did not seem
> feasible to change the default, and but leaving GHC2024 out of the
> release entirely would seem unnecessary.)
>
> Several people have expressed the opinion that we should actively plan
> to switch the default, to benefit one-off use (especially in ghci),
> rather than simply leaving GHC2021 as the default indefinitely. So the
> question is what level of messaging is appropriate before that happens.
> I can see a few options, none of which are entirely satisfying:
>
> * Mention in the release notes (done for 9.10, and easily done in the
> next release).
>
> * Add an off-by-default warning about failure to specify a language
> edition (maybe in -Wall or -Wcompat). Unclear this benefits many people
> because if they aren't specifying a language edition or reading the
> release notes, they may well not be enabling non-default warnings either.
>
> * Enable the warning about failure to specify a language edition by
> default. A bit noisy for ad hoc use.
>
> * Add a warning where NoMonoLocalBinds is used and changing to
> MonoLocalBinds would break the program (since this is the most likely
> source of breakage in practice). This warning could be enabled by
> default if no language edition is specified. Nice for users, but
> probably quite a bit of implementation overhead, so unclear if it would
> be implemented.
>
> * Wait for a super-major release (e.g. the 10.x series) before
> changing the default language. Not clear when this will be.
>
> Any other options? Opinions?
>
> Adam
>
>
> On 19/02/2024 21:34, Eric Seidel wrote:
> > It seems to me that this particular proposal could make sense
> > tactically, but I agree with Chris and Arnaud that it feels
> > like the wrong thing strategically.
> >
> > I don't see us getting away from a notion of a "default language".
> > GCC/Clang similarly implement many C/C++ standards and let users
> > choose, but still define a default standard per compiler version.
> > And this default changes across compiler releases. Forcing even
> > adhoc ghc[i] sessions to specify a language standard feels
> > excessive.
> >
> > Thus, we need *some* cadence for updating the default language.
> > It could be that GHC 9.10 is too soon to make that change, but
> > we should commit to making the change at some point, with proper
> > messaging.
> >
> > Eric
> >
> > On Fri, Feb 16, 2024, at 03:08, Adam Gundry wrote:
> >> Thanks everyone for sharing your thoughts.
> >>
> >> I would point out that this is not just about "the handful of people
> >> that have ghci scripts" but rather anyone compiling modules with ghc
> >> directly (not using Cabal). Were it about ghci alone, I agree that the
> >> latest language edition would be preferable. But it seems likely to be a
> >> larger class, e.g. including educators teaching Haskell, and users with
> >> small programs where they have not created a Cabal package.
> >>
> >> Adam
> >>
> >>
> >> On 16/02/2024 08:36, Arnaud Spiwack wrote:
> >>> (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
> >>> <mailto: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 <mailto: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/ghc-proposals/ghc-proposals/pull/632>
> >>>>>
> >>>>>
> https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0613-ghc2024.rst#introduction-of-ghc2024
> <
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240321/09ad4059/attachment-0001.html>
More information about the ghc-steering-committee
mailing list