ormolu
ormolu copied to clipboard
tweag
Preserve grouping between sections
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 https://github.com/tweag/ormolu/issues/554#issuecomment-616815297, 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, https://github.com/tweag/ormolu/issues/74#issuecomment-568577308 should, along with idempotency, be the core consistency properties ormolu demands of itself. Is that too much to ask?
On July 12, 2020 9:00:40 PM UTC, Mark Karpov [email protected] 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: https://github.com/tweag/ormolu/issues/635#issuecomment-657274344
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
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.
On July 13, 2020 1:31:57 PM UTC, Mark Karpov [email protected] 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: https://github.com/tweag/ormolu/issues/635#issuecomment-657562520
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
I still get splitting behaviour in 0.1.2.0
For type definitions or for everything?
On July 13, 2020 6:12:20 PM UTC, Mark Karpov [email protected] 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: https://github.com/tweag/ormolu/issues/635#issuecomment-657711735
Tested and reproduced for typedefs, function defs, instance decls, do blocks, where clauses, let clauses and case expressions
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
?
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
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
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)
Indeed, we are on the quest of finding balance between normalization and preservation of human-made formatting decisions.
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.
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.