[ghc-steering-committee] #632: Phased introduction of GHC2024
Simon Peyton Jones
simon.peytonjones at gmail.com
Fri Mar 22 09:02:49 UTC 2024
OK, well it clarifies the conversation if the question of a "default
language edition" is basically just "what you get if you type 'ghci'".
(The expectation being that every Foo.hs file will, one way or another,
have an explicitly-specified language edition, so that it continues to work
into the future.)
Very well: perhaps
- The GHCi REPL does the latest stable language edition (and could as
you say even put that in the prompt)
- All other uses of GHC (compiling a Foo.hs module) expect an
explicitly-specified language edition, but use GHC2021 (or even Haskell
98!), and emit a warning to say so, if there none. Essentially we'd be
encouraging users to start every Foo.hs with {-# LANGUAGE GHC2024 #-},
which makes the file admirably self-describing.
I'm playing devil's advocate a bit here. But I used to think that having a
default language edition was obvious, but I have come to realize that it
isn't.
Simon
On Fri, 22 Mar 2024 at 08:20, Adam Gundry <adam at well-typed.com> wrote:
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240322/4abb51e8/attachment-0001.html>
More information about the ghc-steering-committee
mailing list