More global language extensions?

[georgefst]

Right now, hackworthltd/vonnegut#765 is failing because of some HLint warnings about unused extension pragmas. I think these can be useful for some extensions that you really don't want to enable globally (CPP, TemplateHaskell, maybe UndecidableInstances...), so I wouldn't want to disable them, but for others it's just busywork.

It's particularly annoying as they're not reported by HLS for some reason (haskell/haskell-language-server#2042). Otherwise I would have caught the issue before committing.

Anyway, shall we just expand the default-extensions list in our cabal files? Currently we have the following enabled via pragmas, and I don't see any harm in enabling them everywhere:

• ConstraintKinds
• DeriveFunctor
• DuplicateRecordFields
• ExistentialQuantification
• FunctionalDependencies
• GADTs
• NamedFieldPuns
• OverloadedLabels
• OverloadedStrings
• PolyKinds
• TupleSections
• TypeApplications
• TypeOperators

One annoying thing is that we currently have five identical default-extensions lists, for our various components. We could use common stanzas in the cabal files to bring this down to three, but it's still less than ideal. (Roll on GHC2021...)

[dhess]

Can this discussion wait for our Vonnegut post-mortem (#704), or do you think it's more urgent?

(FYI the post-mortem is currently scheduled for next Tuesday Aug 3. I may need to push that until I've returned to the UK but let's keep it scheduled as-is for now.)

[georgefst]

It's definitely not urgent. I'll add it to my notes for #704.

[brprice]

One annoying thing is that we currently have five identical default-extensions lists, for our various components. We could use common stanzas in the cabal files to bring this down to three, but it's still less than ideal. (Roll on GHC2021...)

There is a reason for this, unfortunately. One of the tools - maybe cabal-fmt, or cabal-edit doesn't support common stanzas. Well, actually it expands them when editing the file.

[brprice]

Generally, I agree with adding more extensions to the cabal file. I haven't looked at the list in detail, so may want to quibble over the exact set.

[dhess]

One annoying thing is that we currently have five identical default-extensions lists, for our various components. We could use common stanzas in the cabal files to bring this down to three, but it's still less than ideal. (Roll on GHC2021...)

There is a reason for this, unfortunately. One of the tools - maybe cabal-fmt, or cabal-edit doesn't support common stanzas. Well, actually it expands them when editing the file.

I think practically no Cabal tools support common stanzas.

[brprice]

Some background on the common stanza support: IIRC, cabal itself expands stanzas whilst parsing, and doesn't represent them in its AST of *.cabal files. Then most cabal tools use cabal as a library to read/write the file, which necessarily expands common stanzas.

However, phadej/cabal-fmt#20 says

cabal format inlines common stanzas but cabal-fmt doen't

so perhaps cabal-fmt is a rare tool that doesn't rely on cabal library. (This also taught me that cabal has its own inbuilt formatter!)

See also https://github.com/sdiehl/cabal-edit#limitations which mentions this issue. Upstream info: https://github.com/haskell/cabal/issues?q=label%3Aexact-print+ https://github.com/haskell/cabal/projects/9

[dhess]

Yeah, I also recently discovered that cabal format is a thing. Should we just switch to that? I really don't care at all about Cabal formatting details, so long as it's consistent, and it seems like a good idea in general minimize the number of tools we're using.

[georgefst]

I really don't care at all about Cabal formatting details

I don't much, but cabal format does do a few things that make editing unnecessarily difficult: removing line breaks in default-extensions (and not sorting them), not adding a trailing comma in build-depends...

Then again, maybe I should just get in the habit of using cabal-edit, then I really wouldn't care.

PS. we're getting very off-topic

[georgefst]

Superceded by #140.