Preserve grouping between sections

[hseg]

Consider the following snippet

type SgpF' e = ...
type MonF' e = ...
type GrpF' e = ...
type RigF' e f = ...
type RngF' e f = ...
type FldF' e f = ...

type Sgp = Fix (SgpF' V1)
type Mon = Fix (MonF' V1)
type Grp = Fix (GrpF' V1)
type Rig = Fix (RigF' V1 V1)
type Rng = Fix (RngF' V1 V1)
type Fld = Fix (FldF' V1 V1)

type instance Base Sgp = SgpF' V1
type instance Base Mon = MonF' V1
type instance Base Grp = GrpF' V1
type instance Base Rig = RigF' V1 V1
type instance Base Rng = RngF' V1 V1
type instance Base Fld = FldF' V1 V1

There is a clear, repeating structure. Grouping the declarations this way improves navigation.

Contrast this with ormolu's output:

type SgpF' e = ...

type MonF' e = ...

type GrpF' e = ...

type RigF' e f = ...

type RngF' e f = ...

type FldF' e f = ...

type Sgp = Fix (SgpF' V1)

type Mon = Fix (MonF' V1)

type Grp = Fix (GrpF' V1)

type Rig = Fix (RigF' V1 V1)

type Rng = Fix (RngF' V1 V1)

type Fld = Fix (FldF' V1 V1)

type instance Base Sgp = SgpF' V1

type instance Base Mon = MonF' V1

type instance Base Grp = GrpF' V1

type instance Base Rig = RigF' V1 V1

type instance Base Rng = RngF' V1 V1

type instance Base Fld = FldF' V1 V1

all these declarations are treated equally poorly, ridding one of all navigational clues.

Similarly, spacing between bindings in let/where clauses isn't preserved, as is spacing in do-blocks (this on ormolu 0.0.4.0).

In general, none of #74 is even remotely resolved for me. I echo @michaelpj's concern that this is the main blocker for using ormolu. All the other counterintuitive decisions (type signatures, instance declarations, import lists) I can get used to -- as @mboes notes in #554 (comment), these are microchoices that shouldn't be a programmer's concern. However, code structure is a very different matter. Hyperbolically, this is the equivalent of ormolu flattening the entire project hierarchy. Homogenization of the unimportant details is useful precisely because it brings out the contrast in the important ones.

At minimum, #74 (comment) should, along with idempotency, be the core consistency properties ormolu demands of itself. Is that too much to ask?

[mrkkrp]

Try the latest version of Ormolu, 0.1.2.0.

[hseg]

On July 12, 2020 9:00:40 PM UTC, Mark Karpov ***@***.***> wrote: Try latest version of Ormolu, 0.1.2.0. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #635 (comment)

It appears I've been bitten by #342. The AUR package, while installing ormolu 0.1.2.0, produces an executable that reports (by ```ormolu -v```) that its version is ``` ormolu 0.0.4.0 UNKNOWN UNKNOWN using ghc-lib-parser 8.10.1.20200412 ```

[mrkkrp]

That's specific to building with Nix. I'm not sure that AUR uses Nix to build Ormolu. The version number should be correct in all cases.

[hseg]

On July 13, 2020 1:31:57 PM UTC, Mark Karpov ***@***.***> wrote: That's specific to building with Nix. I'm not sure that AUR uses Nix to build Ormolu. The version number should stay correct in all cases. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #635 (comment)

Ok, did a quick check of the build process AUR uses - seems they only copy the binary and license. Testing, I copied the binary out of ```.stack-work/install``` and indeed got the same ```ormolu 0.0.4.0 UNKNOWN UNKNOWN``` output. Incidentally, ```stack run -- -v``` correctly responds ``` ormolu 0.1.2.0 master b95feb345e14f333988b06be0fc6534694d6d0e9 using ghc-lib-parser 8.10.1.20200523 ``` Checking, I still get splitting behaviour in 0.1.2.0

[mrkkrp]

I still get splitting behaviour in 0.1.2.0

For type definitions or for everything?

[hseg]

On July 13, 2020 6:12:20 PM UTC, Mark Karpov ***@***.***> wrote: > I still get splitting behaviour in 0.1.2.0 For type definitions or for everything? -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #635 (comment)

Tested and reproduced for typedefs, function defs, instance decls, do blocks, where clauses, let clauses and case expressions

[mrkkrp]

What happens if you run Ormolu on this:

{-# LANGUAGE RecursiveDo #-}

foo = do
  rec
    a <- b + 5

    let d = c

    b <- a * 5

    something

    c <- a + b
  print c
  rec something $ do
          x <- a
          print x

          y <- c
          print y

?

[hseg]

What happens if you run Ormolu on this: ...

``` {-# LANGUAGE RecursiveDo #-} foo = do rec a <- b + 5 let d = c b <- a * 5 something c <- a + b print c rec something $ do x <- a print x y <- c print y ```

[mrkkrp]

You are not running 0.1.2.0.

$ cat test.hs
{-# LANGUAGE RecursiveDo #-}

foo = do
  rec
    a <- b + 5

    let d = c

    b <- a * 5

    something

    c <- a + b
  print c
  rec something $ do
          x <- a
          print x

          y <- c
          print y
$ ormolu --version
ormolu 0.1.2.0 master bbcb81203191e088b098b0347fa62d12d4ad9bfd
using ghc-lib-parser 8.10.1.20200523
$ ormolu test.hs
{-# LANGUAGE RecursiveDo #-}

foo = do
  rec a <- b + 5

      let d = c

      b <- a * 5

      something

      c <- a + b
  print c
  rec something $ do
        x <- a
        print x

        y <- c
        print y

[hseg]

You are not running 0.1.2.0.

Indeed. An old local install was shadowing the system version. Sorry for the confusion. Rerunning tests, spaces *are* preserved for do blocks, where clauses and let clauses. However, case expressions, function defs, typedefs and instance decls all break grouping. (case expressions lose spacing, defs and decls all get separated)

[mrkkrp]

Indeed, we are on the quest of finding balance between normalization and preservation of human-made formatting decisions.

[ntc2]

I'm having the same issue. I just started using Ormolu and was shocked to see that it inserts a bunch of blank lines between my data types and their single line instances. E.g.

data D1 = D1
instance T1 D1
instance T2 D1
instance T3 D1

data D2 = D2
instance T1 D2
instance T2 D2
instance T3 D2

gets spread out over a bunch of lines, losing its grouping, and becomes much less readable IMHO.

[ntc2]

This issue has many variations / duplicates, including #685, #681, #802, and #902.

I suggest that Ormolu just preserve groupings in all cases: don't insert blank lines where there were none, and don't remove blank lines where they existed. That will resolve all of these issues.