[ghc-steering-committee] #380 GHC2021: Current status
arnaud.spiwack at tweag.io
Fri Dec 4 12:47:58 UTC 2020
GHC seems to have a bit of an ambiguous take about defaults. For instance,
`MonadFailDesugaring` is turned on since GHC 8.8 (or 8.10, I've been lost
about these lately), regardless of whether you have selected a language in
a Cabal file. It means that, as far as GHC is concerned, Haskell2010 means
Haskell2010+MonadFailDesugaring (and a few friends).
In this particular case, it is, of course, a reasonable assumption that we
are not modifying the meaning of Haskell2010 to that extent (it's the whole
point of shipping GHC2021 as an extension).
I think it would be fair to set GHC2021 as the default language when
launching, say ghci outside of a project.
On Fri, Dec 4, 2020 at 1:41 PM Joachim Breitner <mail at joachim-breitner.de>
> Am Freitag, den 04.12.2020, 07:33 -0500 schrieb Eric Seidel:
> > Is the expectation that GHC2021 remains the new default behavior, or
> > will GHC2022 replace it as the default? I ask because tying these
> > standards to GHC’s default behavior will make it much harder to
> > correct mistakes or migrate to new designs of extensions (eg
> > LambdaCase). Requiring an explicit opt-in to a GHC20XX standard means
> > that users can upgrade to a new compiler and adapt to the new
> > standard separately, which is very useful in larger enterprises.
> The use case you are describing (larger enterprises) probably mean you
> are using Cabal, which forces you to declare a default-language
> anyways. So that makes it opt-in, and all is well, I hope.
> The “default” mode, as far as I know (please correct me if I am wrong)
> mainly applies to your one-shot script that you run, and of course
> interactive use in GHCI. Especially for the latter, I find it very
> appealing to have the full syntax without turning on extensions, hence
> my hope that the latest GHC202x is the default. And with these modes,
> some breakage is acceptable maybe.
> Do others see this differently?
> Joachim Breitner
> mail at joachim-breitner.de
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-steering-committee