[ghc-steering-committee] #632: Phased introduction of GHC2024
Adam Gundry
adam at well-typed.com
Fri Mar 22 08:20:42 UTC 2024
On 21/03/2024 10:08, Simon Peyton Jones wrote:
> 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).
We certainly should encourage them to specify a language edition for
every module that will last for any length of time. But that still
leaves quick one-off uses, either just firing up ghci, or writing a
throwaway module. And there it's less obvious how active our
encouragement should be.
> 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.
The downside of this is that simply typing "ghci" will give the user a
suboptimal experience (at least if we assume that future GHC20xx
revisions will be better than GHC2021). So we potentially end up in a
situation where expert users have learned to use "ghci -XGHC2035" but
beginners use "ghci" and encounter unexpected papercuts.
In the extremely long term, perhaps we won't want to support GHC2021
forever, but if we don't have a story about evolving the default
language, we are stuck. I think we are better off having a clearly
identified default language per compiler version, but making users aware
of when they are relying on that default.
Side thought: maybe "ghci" should print the language edition in use as
part of the initial prompt, at least where the default was not overridden?
Adam
> On Thu, 21 Mar 2024 at 09:08, Adam Gundry <adam at well-typed.com
> <mailto: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>
> >>> <mailto: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>
> <mailto: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>
> >>>> <mailto: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>
> >>>>> <mailto: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>
> <mailto: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/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> <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
More information about the ghc-steering-committee
mailing list