Revisit default GHC extensions

[dhess]

Let's revisit the default GHC extensions we're using.

@georgefst suggested using the upcoming GHC2021 standard as a starting place. [Rendered.]. Unless that's backported to GHC 8.10, we won't be able to use it directly until we drop support for GHC 8.10, which likely won't happen for a long time, but we could just copy all of the extensions it enables into our Cabal files.

I'll maintain a list of specific extensions we've considered here:

• ❌ BlockArguments

[georgefst]

Extensions which we currently have under default-extensions and aren't in the GHC2021 set:

• DataKinds
• DerivingStrategies
• DerivingVia
• LambdaCase
• OverloadedStrings

All were only 1 or 2 votes (out of 11) short of making the cut, except DerivingVia (3). Which indicates they may well be included in future anyway.

I see no reason to remove any of these.

Some others which we use a lot and might consider adding to default-extensions:

• OverloadedLabels (regardless of the outcome of Investigate performance implications of generic lenses vs TH #141)

[dhess]

How on earth did OverloadedStrings not make the cut?

[georgefst]

How on earth did OverloadedStrings not make the cut?

I believe there have been proposals about improving it in potentially non-backwards-compatible ways, perhaps with configurable default rules? But I can't really find anything right now. (I also recall something about ByteString having a dodgy IsString instance, although that seems like more of a library problem.)

Similarly for LambdaCase, which I think didn't make it due to ghc-proposals/ghc-proposals#302.

[brprice]

One small pitfall I have run into related to this is that fourmolu does not (for good reason) by default turn on some language options (in particular TypeApplications). Thus if we turn on GHC2021 or equivalent in the cabal file and remove pragmas from individual source files, we may get errors from fourmolu along the lines of

The GHC parser (in Haddock mode) failed:
  exe/Swagger.hs:16:20
  parse error on input `@'

This is easily worked around by one of

• Telling fourmolu to turn it on with --ghc-opt -XTypeApplications (this seems to be integrated into pre-commit-hooks.nix via settings.ormolu.defaultExtensions (note ormolu here - the option is shared between ormolu and fourmolu)
• Waiting for Allow specifying Ormolu CLI flags in config file fourmolu/fourmolu#58 or Merge ormolu changes fourmolu/fourmolu#106 to be merged and then upgrading fourmolu, as it will (probably) pick up cabal options by default in the future.
• (For type applications in particular, Merge ormolu changes fourmolu/fourmolu#106 will also enable the extension by default due to ghc parser changes)
• Just keeping the individual pragmas around in each relevant source file.

[georgefst]

One small pitfall I have run into related to this is that fourmolu does not by default turn on some language options

fourmolu/fourmolu#106 is now merged and released, so we should get TypeApplications by default and others picked up from the cabal file.

[dhess]

As of #491, we will be on the GHC2021 language set. It's probably time to close this issue once that merges, yes?

[georgefst]

As of #491, we will be on the GHC2021 language set. It's probably time to close this issue once that merges, yes?

Before we do, I think it's worth thinking about records. We have a smattering of duplicate field names, puns, wild cards, and dot syntax in certain modules. I'd be happy with enabling all of these globally, but maybe we want to be more consistent, avoiding having a lot of ways to do the same sort of thing, e.g. for onboarding reasons.

Eventually I'd like to enable NoFieldSelectors globally, since I think it's necessary to make duplicated field names usable in general, and we can use the aforementioned extensions (and lenses) for access instead. But it's best to keep it in select modules for now, since dropping record selectors completely would require a lot of (trivial) changes to the codebase.

https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/records.html

[brprice]

Re records: yes, we should revisit this. I would be happy with puns and dot syntax. I'm not sure how useful duplicate field names is without NoFieldSelectors, but am happy with it. I am less sure about wild cards, since they can make it rather unclear where an identifier is bound, as you mentioned in #692 (comment)

[georgefst]

DuplicateRecordFields can be useful with puns and wild cards, even with FieldSelectors. I'd be happy to agree to a preference for dot syntax (over puns and, especially, wild cards).

Shall we enable OverloadedRecordDot globally then? (I had been thinking that it was a change that had to be embraced globally to be useful, but having just tried it, it's enough to enable it in any module which wants to use it, even if it's off in the module defining the record type we want to use it on. Still, I don't see any reason not to go for it.)