Ormolu (and, by default at least, Fourmolu) turns this:
into this (in my opinion) ugliness:
This was partially covered here: Comment placement on then/else branches · Issue #998 · tweag/ormolu · GitHub but not fully (note the extra empty line). I’m like asking myself… why would it do such a thing?
Please share your opinions. Are there known workarounds?
I agree this is pretty weird! (I’m a regular ormolu user.)
Like (almost 
always, adding a “do” fixes problems with comment placing in Fourmolu (don’t know if that works with Ormolu).
if True
then do
-- fsfajk djaskflkdsj fdsjf
1
else 2
…and can cause so many more, as the designers of Rust discovered back when the the language had its own “two-letter keyword” :
A longer time ago (in 1996) the monadic interface was introduced to
Haskell, along with the more-convenient imperative-style syntax for
monadic expressions first implemented in Gofer two years earlier. The
specifier chosen for this alternate monadic syntax was a very small
and reasonable keyword: do.
But the monadic interface had an irritatingly-odious complexity bill
(e.g. requiring much formerly effect-free code to be manually rewritten
monadically) and still had people breaking the rule with unsafe
entities (often for I/O), which meant that the putative benefits like
“can do compile time evaluation” or “can spread on a GPU” weren’t there
anyways. And people couldn’t do simple things like “put a print in here
for logging” (which is possible in Standard ML).
So will everything eventually be marked do, thereby reducing it to
a noise word in Haskell? Or will this lesson of PL-design history be
heeded?
It’s ugly - at the very least, it should have re-indented the following lines, too:
if foo == 2
then -- Yes. More comments [...]
-- comments. [...]
"yes"
else -- No. More comments [...]
-- comments. [...]
myfunc
"no"
"nfo"
…but what you originally wrote seems the tidiest, at least to me.
adding a “do”
But… my code is pure.
I hope I don’t have to introduce an Identity/runIdentity/do just to make a formatter do a less ugly thing.
You left out the most important part in your citation.
Maybe I should emphasise
a “do” fixes problems … in Fourmolu
Personally, I wouldn’t do 
that, but it is a workaround.
No, using do won’t require you be in a monad. do True && False is just False, no monad in sight.
“Like (almost ;-) always” ? That seems rather generic to me, even for Fourmolu…
A do pins comments after it somehow. Like:
foo a = b
-- dfasdf
foo c = d
gets formatted to
foo a = b
-- dfasdf
foo c = d
but
foo a = do b
-- dfasdf
foo c = d
preserves the empty line.
So the OP has to choose between:
That seems like a “lose-lose-lose-lose situation” to me…unless someone knows of a better-behaving code formatter that the OP can try using.
Open a ticket in f/ourmolu repo and meanwhile:
{- FOURMOLU_DISABLE -}I’d prefer this bullet list:
Hi, fourmolu maintainer here. Please ticket in Ormolu, not Fourmolu, because Fourmolu doesnt change anything here
Also, I’d advise against FOURMOLU_DISABLE here; I think the README specifies that it should only wrap top-level declarations. I don’t think it’ll work well inside a function.
But I agree that it’s a bug. Which is why I commented in that Ormolu issue. As to why: comments are printed automatically in Ormolu whenever a term with comments attached is printed. It works most of the time, but oddities can occur in certain contexts.
…which can be reduced to:
where possible, provide remedial patches instead of ugly workarounds