search

tweag / ormolu

A formatter for Haskell source code
https://ormolu-live.tweag.io
Other
958 stars 83 forks source link

Placement of comma for lists, records, tuples, function type signatures... #710

Closed lehins closed 3 years ago

lehins commented 3 years ago

TLDR It is unreasonable to start putting commas at the end of lines.

There was a ticket already on this topic that was about making this configurable in #497

In this ticket, however, I am not proposing making ormolu configurable. This issue is about changing the default, because current formatting choice is vastly worse than what the defacto Haskell style is.

Of course, my personal preference plays a role in me opening this ticket, but I will put it aside and will show facts instead.

I have looked at arguments in the blogpost in favor of comma placement at the end rather that at the beginning:

Multiline pattern matching

While this popular formatting choice works in expressions, it’s a parse error if used in a pattern, because everything in a multiline pattern should be more indented than the opening parenthesis.

Multiline pattern matching in case statements is rather uncommon, especially when compared with popular formatting choice. I even had to google it in order to see what it actually means.

For anyone reading this here is an example. These two will parse:

bar :: Num a => [a] -> a
bar [ x
    , y
    , z
    ] = x + y + z
baz :: Num a => [a] -> a
baz xs =
  case xs of
    [ x,
      y,
      z ] -> x + y + z

But this will not:

baz :: Num a => [a] -> a
baz xs =
  case xs of
    [ x
    , y
    , z ] -> x + y + z

For the curious here is a ghc issue that tries to improve the error message about it. IMHO it would be better to fix ghc to support such syntax, rather than use it as an argument to change formatting style.

Trailing comma is now supported by ghc

module Foo 
  ( foo,
    bar,
  ) where

vs

module Foo 
  ( foo
  , bar
  ) where

Did you notice that we also add trailing commas where possible, for example, in export lists? Our ability to do this comes from a relatively new feature in Haskell—it helps with Ormolu’s goal of achieving minimal diffs too. If we try to remember where leading commas come from, Johan Tibell’s style guide comes to mind. The author said later:

"[…] I designed [Haskell style guide] to work with the lack of support for a trailing comma. If we supported a trailing comma my style guide would probably be different."

There you have it: GHC supports a trailing comma now, so it’s not unreasonable to start putting commas at the end of lines.

That argument works for exports only and we do lack trailing comma support, so Johan Tibell's design is still valid.

Coming from other languages

This style is also more familiar to programmers who come to Haskell from other languages.

I think this is the worst argument of all. We don't need to change the style that people used for decades just because other languages do it and new people are accustomed to it. Haskell is unique in many aspects and many of those aspects is what makes it very powerful.

Negative affects of comma placement

I really don't think that above arguments are strong enough to enforce the same style in all other places affected by that decision:

If we did have the ability to place trailing comma at the end of all of these, then it probably would not be such a big deal, just as Johan Tibell said. Because then the only downside is that we have to type an extra symbol per line and possibly adjust our eyes a bit. However trailing comma is not possible and it is unlikely that ghc will ever change that. It'll definitely never be adjusted for tuples, since trailing comma in tuples implies TupleSections.

The downside of this style without support for a trailing comma is significant IMHO, because it has a very negative impact on the git diff. Here are two sample diffs:

@@ -32,9 +35,11 @@ tuples :: ( String , String , VeryLongTypeNameThatCausesForTupleiInTheTypeSignatureToWrapAroundTooAmIRight

We clearly get one unnecessary line of diff for every place where we append an element at the end.

mrkkrp commented 3 years ago

Indeed, the diffs are unfortunate. It looks like we need to make trailing commas accepted by GHC in more contexts instead of changing their placement in Ormolu.

lehins commented 3 years ago

It looks like we need to make trailing commas accepted by GHC

As I said, trailing comma will never be accepted by GHC for tuples, because it conflicts with TupleSections

λ> :set -XTupleSections
λ> :t ('b', "Foo",)
('b', "Foo",) :: t -> (Char, [Char], t)

@mrkkrp Out of curiosity, why are you so firmly set on changing this style that has been around and worked well for so many years? None of the arguments in its favor make sense to me.

mrkkrp commented 3 years ago

@lehins In this kind of discussion no argument of ultimate convincing power is possible. I could confabulate an answer of a comparable length, yet I lack time and the appetence to do that. The simplest reason why this is not going to change is that it would cause a lot of reformatting in existing projects, which we do not want.

lehins commented 3 years ago

In this kind of discussion no argument of ultimate convincing power is possible

If I only knew that I would not bother wasting my time on this. I'll make sure not to make that mistake twice.

The simplest reason why this is not going to change is that it would cause a lot of reformatting in existing projects, which we do not want.

If I understand you correctly, you are saying that whatever wrong decisions you have made about formatting style will never be fixed. Moreover, without lack of configuration users don't even have a choice of opting in for a fix, they are simply stuck with those bad decisions. Does not seems like a good policy/design decision to me. But hey, who am I to complain at free software. I wish you all the luck with this project.

anka-213 commented 3 years ago

Well, this is why fourmolu exists. 😉 Those who disagree with the formatting choices of ormolu but still want a similar engine can tweak fourmolu to their liking (or in this case, keep fourmolu's default config), while those who prefer zero config can keep using ormolu.

dpwiz commented 3 years ago

The simplest reason why this is not going to change is that it would cause a lot of reformatting in existing projects

Wait... but... that's what formatters do.

mrkkrp commented 3 years ago

@lehins came here with toxic behavior from the start. He states right away "your decisions are bad, here are the right choices you should have made." We hear this in the first sentence:

It is unreasonable to start putting commas at the end of lines.

Just how brash and arrogant is this? We thought about the decisions we made. Then he proceeds to "prove" his point of view by disregarding our arguments as "rare" or in his opinion bad and regarding his arguments as important. I'm sorry, but it's not a proof. It is an opinion. I have my opinions, too. I also have the mission to make this project stick to some style, which is what I do.

This is not math where one can have a proof. This is the realm of psychology. What most likely is happening here is that @lehins is fixed too much on the way the code is formatted; he wants to continue seeing code as he used to see it for many years of writing Haskell. Why change? It worked for me! That emotional decision is what makes him fabricate arguments—disregard ours and assign high importance to his in order to concoct a pretext for the change to the good old style that he wants.

anka-213 commented 3 years ago

While I find the idea of coming up with a new "one true formatting style" for a language that has already existed many years quite flawed, especially when that style significantly differs from most common styles in use, there is really no point in coming to a project like this and complaining about the style that was chosen and demanding that they flip arbitrary choices to do the opposite. All that achieves is more frustration from all parties and people getting discouraged.

@mrkkrp Perhaps you could add an FAQ item that points to fourmolu for those who disagree with design choices or want config, or would doing that run counter to your goals with this project? I'm hoping that increasing the awareness of alternatives could lessen the frustration for all parties, since fewer people would come here to complain and those who dislike the choices know that they can just use fourmolu to get the style they want.

mrkkrp commented 3 years ago

@anka-213 Would you like to open a PR to add this to the readme?

lehins commented 3 years ago

@mrkkrp I did not come here with any toxic behavior! I opened an issue because I saw a problem with the tool. I clearly described the problem and presented my reasoning with arguments why the decision about comma placement was bad. You made it clear that there is no argument that is convincing enough to change your mind, so I closed the ticket and moved on with my life. Then you come out at me with all these accusations!? What a hell?

I was not being "brash and arrogant". I took these words from your blogpost verbatim!

This is what I said:

It is unreasonable to start putting commas at the end of lines.

as a response to your statement in the blogpost:

...., so it’s not unreasonable to start putting commas at the end of lines.

image

I clearly stated and presented examples that prove: "Git diff is negatively affected!" That was the whole point of this ticket! But you instead go on on a rant about how I "fabricate arguments".

I also pointed out that your argument is wrong and GHC does not support trailing commas, to what your reply was "It looks like we need to make trailing commas accepted by GHC". ExtraCommas initiative has already wasted enough time and energy of too many people. It has been abandoned and removed from accepted proposals: https://github.com/ghc-proposals/ghc-proposals/pull/87#issuecomment-596538552 All of the people I've ever asked about leading commas prefer that style. Even the ghc proposal itself notes that: "Haskell appears to be one of the only languages that generally prefers leading commas for lists of any sort.". If that is one more thing that makes us unique, so be it. Time to let it go.

Just because you made a wrong decision on the formatting style that you are too proud to admit and back out from doesn't give you the right to accuse people who point it out with concrete examples (not fabricated arguments) that it was a mistake.

How in the hell can you speculate on what is happening if you didn't even try to understand what was described in this ticket in the first place!!?? I can speculate about what is happening too. What most likely is happening here is that @mrkkrp is trying to impose his personal preference of the Haskell code formatting style onto the community, disregarding any feedback that he is receiving. This point is easily supported by the fact that there is an exact fork of this project named fourmolu that actually does take input from other community members and allows its users to configure the formatting style.

Now, that was my opinion! See the difference?

mrkkrp commented 3 years ago

@lehins There is no need for violent outbursts. I understand your original request perfectly, however it is not unequivocal that it is an improvement. You don't like commas at the end of lines, but quite a few people actually praised this decision. It is important to understand that there exist opinions that are different from yours and they should be respected.

It is true that I am presently quite adamant about preserving the status quo, but not because I'm particularly keen on this style (the idea to place commas at the end is not even mine, it was devised collectively at the early stages of Ormolu development), but because it is my duty to avoid unnecessary changes and keep the project stable. Given our policy of having only one style, it means rejecting requests like this.