Make commas optional in "build-depends"

[nikita-volkov]

Reasons:

1. There is no real need for the comma. People almost never use more than 1 line for specification of 1 dependency. So its role as a separator is pretty much redundant.
2. For the same reason the change will be backwards compatible for the majority of existing packages.
3. Consistency. Sections like default-extensions and exposed-modules already behave this way.
4. Clarity. Less syntactic noise.

To make it abundantly clear I suggest to make the following syntax valid:

  build-depends:
    base >=4.12 && <5
    bytestring >=0.10 && <0.12

In addition to the following already supported variations:

  build-depends:
    base >=4.12 && <5,
    bytestring >=0.10 && <0.12

  build-depends:
    base >=4.12 && <5,
    bytestring >=0.10 && <0.12,

  build-depends: base >=4.12 && <5, bytestring >=0.10 && <0.12

[chshersh]

I didn't know trailing commas are supported in build-depends! I've been using leading commas all the time (I prefer them more anyway):

  build-depends:
    , ansi-terminal        ^>= 0.11
    , directory            ^>= 1.3
    , bytestring            >= 0.10 && < 0.12
    , mtl                   >= 2.2  && < 2.4
    , optparse-applicative ^>= 0.17
    , process              ^>= 1.6
    , text                  >= 1.2  && < 2.1
    , unliftio-core        ^>= 0.2

But I'd rather not write any commas at all and I'd be happy with the line break as a separator (as long as error messages are comprehensible).

[Mikolaj]

I vaguely remember, with high enough cabal-version: in .cabal file, you don't need commas at all. Could you verify?

[ulysses4ever]

I vaguely remember, with high enough cabal-version: in .cabal file, you don't need commas at all. Could you verify?

Nope, I just checked, and it doesn't seem to be the case. Also, the doc says:

Some fields take lists of values, which are optionally separated by commas, except for the build-depends field, where the commas are mandatory.

I'm guessing, given the reach language of constraints, it may be a little tricky to pick one the two modes (commas v. no commas).

But ultimately, our parser story is lacking, so I'm not sure who'd go for adding new features at the moment.