I'm not sure that comment behavior is so bad, as long as the newline is added before the comment. I cannot recall seeing a reasonable coding style that has comments lines on the next line after a statement, without a blank line separating them. A comment with a block of code right and no newline should apply to that block of code, and that means it's the first thing in the block, so it should be separated by a newline from any previous block.

That makes sense @cdsmith . I also don't think a comment squashed between two lines of code is common.

What do you think @mrkkrp? If you like the current behavior, you can merge the PR as-is, or let me know and and I'll modify the PR.

FWIW there is some precedent here. The Starlark formatter does exactly the same thing: it always puts a newline before a comment, even when it wasn't there before. It takes some getting used to at first.

I think we should follow spacing decisions made by the original author of the source code. That means that we should only insert newlines before comments when there were one or more blank lines in the input. How to do it? That's a good question.

To be able to tell whether a line is blank or not, we'd need access to the original input or to the comment stream. Introducing something to keep original input just for this purpose seems overkill given that we managed to go so far without it. With comment stream it is also tricky because it is an ordered list which is "consumed" as we go and you seem to do the analysis before the statements are printed.

I'd try to go in a different direction with respect to the implementation. We've solved almost exactly the same problem but with narrower scope: we know how to insert blank lines between comments. This is done by using low-level stateful setLastCommentSpan and getLastCommentSpan functions. See how we use them in Ormolu.Printer.Comments. The idea is that whenever we print a comment we register its span and then we check this info to decide if we should add a newline before next comment. When something other than a comment is printed this info is reset automatically.

I think we could do something similar just for statements in a do-block. Maybe exactly the same part of state of the R monad can be extended to remember not just comments but also position of last printed lexeme? Then implementing insertion of blank lines is a matter of adding a couple of conditionals.

At any rate, this is not the simplest issue.

With comment stream it is also tricky because it is an ordered list which is "consumed" as we go and you seem to do the analysis before the statements are printed.

I feel like traversing the comment stream before printing the do statement might be an easy solution here, don't you think? It has the advantage of not adding a stateful internal state. I'll try if it works.

Thinking about it, I think just preserving a list of empty lines from the source code is a better approach.

It conceptually makes sense. Since by definition of this issue we're adding a meaning to the empty lines, and it makes sense to just store that information instead of trying to infer it indirectly by looking at the source locations of expressions and comments.

@mrkkrp I tried another approach (traversing the comment stream to figure out if there are comments), now it formats the comments as you suggested. What do you think?

Indeed, this appears to work. Still, the solution feels a bit hacky and not entirely straightforward. I'd like to try to implement it using the approach I described earlier and compare the results.