[ghc-steering-committee] #380 GHC2021: Current status

[Eric Seidel]

On Fri, Dec 4, 2020, at 07:41, Joachim Breitner wrote:
> 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.

Do Bazel/Buck/etc reuse Cabal or do they reimplement the build themselves? I haven't used either (at Bloomberg we use cabal and stack, and good point about default-language, I forgot that was required), but my impression is that Bazel likes to reimplement everything so it can see precise dependencies, have granular caching, etc.

> 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.

Agreed that having a complete set of extensions in GHCi by default would be very nice, and the potential for breakage is not so concerning there. I'm less sure about the potential for breakage in standalone scripts using runghc or the stack/cabal script feature. I don't think I use that mode anywhere, so I don't have a good intuition for how people use it. If these scripts are deployed to "production" I'd be pretty concerned about the potential for breakage, but if they're just used for ad-hoc tasks I'd be less concerned. (One thing to note is that stack scripts at least will specify a particular ghc version via the resolver, so we don't have to worry there.)

All that said, if the argument is that we expect all "serious" uses to specify a default-language via Cabal, and thus have to explicitly opt into GHC2021, then why shouldn't we make some bold choices?