Open dhess opened 3 years ago
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 #141)How on earth did OverloadedStrings
not make the cut?
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 https://github.com/ghc-proposals/ghc-proposals/pull/302.
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
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
)fourmolu
, as it will (probably) pick up cabal options by default in the future.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.
As of #491, we will be on the GHC2021 language set. It's probably time to close this issue once that merges, yes?
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
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 https://github.com/hackworthltd/primer/pull/692#discussion_r972073210
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.)
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