brittany doesn't format newlines

[samuela]

It seems as though brittany doesn't do anything to normalize the number of newlines between definitions:

module Lib
    ( Tensor(..)
    )
where

data Tensor = Tensor {val :: String, foo :: String} deriving (Show)

isn't changed at all by brittany.

[tfausak]

I think this is intentional. The idea is that if you want to put some new lines between tricky bits of code that aren't necessarily separate declarations, Brittany will allow that. Also it allows for many styles of top-level formatting:

-- dense
foo = this
bar = that
baz = other

-- normal
foo = this

bar = that

baz = other

-- spacious (like python?)
foo = this

bar = that

baz = other

I think that's the current rationale, anyway. It would be nice if this was somehow configurable.

[samuela]

@tfausak Right, though it would be nice if there was some kind of consistency, ie. "at most 1 line between declarations" seems like a decent rule.

[ElvishJerricco]

I actually rather prefer that brittany doesn't ever mess with my blank lines. Sometimes a lot of space is intentional. I wouldn't mind seeing this as an config option though.

[eborden]

My preference is, no messing with new lines and no configuration.

1. Extra whitespace or lack there of, as previously mentioned, is usually intentional.
2. Extra configuration just adds more complexity to brittany and makes it more challenging to maintain and evolve. As it currently stands I'd like to shed some of the existing configuration.

[samuela]

Extra whitespace or lack there of, as previously mentioned, is usually intentional.

I would say that this may be the case on smaller projects with fewer contributors, but once you get loads of people contributing to the same codebase with different ideas of what spacing should look like it quickly becomes a mess. I also think it's worth pointing out that the same argument could be made for the rest of brittany's feature set or for any code formatting at all, eg. the user's idea of formatting

x-  (  y/ 3)--blah blah

was probably intentional, and therefore we shouldn't touch it.

In my view the whole point of code formatting is uniformity, and that's most people tend to expect from tools in this category.

[lspitzner]

I think this feature can be implemented in a way that does not intersect with other stuff, either by using a mapping on the annotations (we already pre-process them, so composing one more function is not really complex) or by giving the BDAnnotationPrior a new argument. The latter would touch a few places, but still be fairly contained.

So in this case I am currently leaning towards "this additional complexity might be worth it".

I agree that this should be disabled by default.

However, there are a couple of annoying design/requirement questions that I would like to address before approaching an implementation:

• How to handle comments? I know formatters for other languages that have this feature enabled by default, and that move comments rather strictly down to the next decl. E.g.

  foo :: Int
  foo = 42
  -- 42 is a nice number                       -- move this down?
  
  adder :: Int -> Int
  adder = (+5)

  Do you want to move the comment? What if there is a newline before the comment, too?

• I assume that we want to keep type signature and corresponding equation together, no matter what. Even though both are distinct top-level elements.

  There also is the question of how to treat this:

  foo, bar :: Int
  foo = 10
  bar = 12

  This might not be so bad if we only ever delete too-many newlines, but for standardisation this is very relevant.

• This applies to nested decls too, right? Or not? members of type class defs and instances too? between let/where elements? Is this configurable separately?