Elm-format: More flexible handling of infix operators

[Fresheyeball]

I'd like to throw out there that instead of special casing <| we just give more flexibility to infix operators, and not manipulate them by default. Instead if a operator is found on a new line, elm-format could line it up with other operators found on new lines, but leave them alone otherwise. Right now I find myself frequently adding parenthesis to stop elm-format from making my code less readable.

If I wrote the following, I'd prefer elm-format not alter it in any way:

foo x =
    fn ++ bar 
    <| a 1 
    <| b 2 ++ baz 
    <| c 3

I don't find the above code to be unreasonable, or unreadable.

[avh4]

Thanks for the suggestion.

For this type of discussion, can you please provide one or more examples of code from real projects where you've run into this? (Examples from other people are also welcome.)

[Fresheyeball]

http://package.elm-lang.org/packages/Fresheyeball/elm-guards/1.0.0/ This lib gets less readable after formatting.

[Fresheyeball]

Here is an example I find displeasing from my code

        submittable =
            List.length (Form.getErrors form)
                == 0
                && Maybe.isJust (Form.getOutput form)

vs un-formatted

        submittable =
            List.length (Form.getErrors form) == 0
                && Maybe.isJust (Form.getOutput form)

[Fresheyeball]

contrived but I've seen it (though I can usually find a pleasing work around)

foo = 
    bar 
    == baz
    ++ [1,3,4]
    && qua
    && pum 
    == pumm
    |> List.filter 
    << always

vs user defined space to delimit _ideas_

foo = 
    bar == baz ++ [1,3,4] 
    && qua
    && pum == pumm
      |> List.filter << always

[Fresheyeball]

Last thought, consider the infixing of 'andThen' when paired with lambdas. This issue could resolve that as well without resorting to special caseing.

[avh4]

For reference, the previous comment about andThen refers to https://github.com/avh4/elm-format/issues/187

[Fresheyeball]

I wrote this lib in an effort to "flatten" some ideas. I have >>| aliased to 'andThen', please add the example from the readme to your considerations.

[Fresheyeball]

https://github.com/Fresheyeball/elm-return

[trotha01]

Just to add another data point, I did run into this when doing basic collision detection, but elm-format forcing the use of parenthesis seemed to work out nicer in this case.

collide : Box -> Box -> Bool
collide box1 box2 =
    not
        (box2.left
            > box1.right
            || box2.right
            < box1.left
            || box2.top
            > box1.bottom
            || box2.bottom
            < box1.top
        )

collide : Box -> Box -> Bool
collide box1 box2 =
    not
        ((box2.left > box1.right)
            || (box2.right < box1.left)
            || (box2.top > box1.bottom)
            || (box2.bottom < box1.top)
        )

[avh4]

The current elm-format recommendation is to use clarifying parenthesis in long binary operator expressions. Removing this from the 0.6.0 milestone.