Allow group lists (build-depends, default-extensions, etc.) by comments and/or empty lines

[ruifengx]

Currently, lists are sorted in alphabetical order. This has the following surprising (for me, at least) consequences:

• array is sorted before base
• all comments in the list gets moved to the very beginning
• empty lines are removed

Therefore, I do not see a way to maintain my dependencies in groups, where each group contributes to a certain functionality of my package. I propose to change the behaviour to treat comments and/or empty lines as group separators, and only sort within the groups.

As a minor point, I do think base should always appear first in the dependency list, so maybe it can be considered as a special case when sorting the dependencies. However, I understand not everyone will agree with this ordering, and I am all satisfied if at least I can use grouping to force the ordering.

[tfausak]

As a workaround, instead of this:

build-depends:
  -- comment about foo
  foo,

  -- comment about bar and baz
  bar, baz

You can do this:

-- comment about foo
build-depends: foo

-- comment about bar and baz
build-depends:
  bar,
  baz,

With regard to comments and empty lines, they are hard to retain in general while formatting. For example, consider a package description like this:

build-depends:
  base
    -- ghc 9.8
    ^>= 4.19.0.0

    -- ghc 9.6
    || ^>= 4.18.0.0

How should the empty lines and comments be retained while formatting the constraints? Especially considering that package descriptions don't have inline comments. I think Gild does the reasonable thing, which is to format the constraints and retain the comments but collect them all at the top. See phadej/cabal-fmt#67 for more discussion about this.

As for sorting base at the top, I'm not in favor. I understand that it's kind of special, but so are other packages like ghc or template-haskell. I could see an argument for sorting non-reinstallable packages (haskell/cabal#9092) before regular ones, but I doubt that would be worth the effort.

[ruifengx]

Thanks, that makes sense. I am happy with the multiple build-depends workaround. I think it even makes more sense visually than my original proposal, and it can be easier to refactor into a common stanza.