Nesting |> andThen consumes too much indent

[jinjor]

Today I first tried elm-format and shocked with this result. It consumes 12 spaces per one chain.

-  model.floor
-    |> Maybe.map EditingFloor.present
-    |> Maybe.andThen (\floor -> List.head (selectedObjects model)
-    |> Maybe.andThen (\primarySelected ->
-      ObjectsOperation.nearest direction primarySelected (Floor.objects floor)
-    |> Maybe.map (\object ->
-      { model |
-        selectedObjects =
-          List.map Object.idOf [object]
-      }
-      )))
-    |> Maybe.withDefault model
+    model.floor
+        |> Maybe.map EditingFloor.present
+        |> Maybe.andThen
+            (\floor ->
+                List.head (selectedObjects model)
+                    |> Maybe.andThen
+                        (\primarySelected ->
+                            ObjectsOperation.nearest direction primarySelected (Floor.objects floor)
+                                |> Maybe.map
+                                    (\object ->
+                                        { model
+                                            | selectedObjects =
+                                                List.map Object.idOf [ object ]
+                                        }
+                                    )
+                        )
+            )
+        |> Maybe.withDefault model

In Haskell, this may be flattened by do notation. So I don't think the former style is too strange.

Another alternative would be the following style.

+    model.floor
+        |> Maybe.map EditingFloor.present
+        |> Maybe.andThen (\floor ->
+            List.head (selectedObjects model)
+                |> Maybe.andThen (\primarySelected ->
+                    ObjectsOperation.nearest direction primarySelected (Floor.objects floor)
+                        |> Maybe.map (\object ->
+                            { model
+                                | selectedObjects =
+                                    List.map Object.idOf [ object ]
+                            }
+                        )
+                )
+        )
+        |> Maybe.withDefault model

This is 8 spaces per one chain.

And this is 4 spaces.

+    model.floor
+        |> Maybe.map EditingFloor.present
+        |> Maybe.andThen (\floor -> List.head (selectedObjects model)
+            |> Maybe.andThen (\primarySelected -> ObjectsOperation.nearest direction primarySelected (Floor.objects floor)
+                |> Maybe.map (\object ->
+                    { model
+                        | selectedObjects =
+                            List.map Object.idOf [ object ]
+                    }
+                )
+            )
+        )
+        |> Maybe.withDefault model

I found this was once discussed before. No progress on this issue since then? I don't have clear idea but wanted to bring it up again before public release. Is it possibly true that elm-lang/core will be formatted in the future? It has similar code too.

I'm facing a similar problem.
It's hard to spot errors where Json.Decode.mapX has its arguments in the wrong order, so we are using the next best thing that Elm has to a do notation, which would look something like

decodeEngineResult : Decoder Rules.EngineResult
decodeEngineResult =
    Decode.field "consideredCount" Decode.int &> \consideredCount ->
    Decode.field "evaluationCount" Decode.int &> \evaluationCount ->
    Decode.field "matchedCount" Decode.int &> \matchedCount ->
    Decode.field "time" Decode.string &> \time ->
    Decode.succeed
      { consideredCount = consideredCount
      , evaluationCount = evaluationCount
      , matchedCount = matchedCount
      , time = time
      }

However, elm-format formats the above to:

decodeEngineResult : Decoder Rules.EngineResult
decodeEngineResult =
    Decode.field "consideredCount" Decode.int
        &> \consideredCount ->
            Decode.field "evaluationCount" Decode.int
                &> \evaluationCount ->
                    Decode.field "matchedCount" Decode.int
                        &> \matchedCount ->
                            Decode.field "time" Decode.string
                                &> \time ->
                                    Decode.succeed
                                        { consideredCount = consideredCount
                                        , evaluationCount = evaluationCount
                                        , matchedCount = matchedCount
                                        , time = time
                                        }

Which is a lot more difficult to read.

BTW, thank you for elm-format. Despite its little shortcomings it's a fantastic tool, I just don't write Elm without it. Please let me know if I can help.

[avh4]

I agree that I think we should find a better way to format this.

However, in @xarvh-at-stax's example, it can be cleaned up using NoRedInk/elm-decode-pipeline:

import Json.Decode.Pipeline exposing (decode, required)

decodeEngineResult : Decoder EngineResult
decodeEngineResult =
    decode EngineResult
        |> required "consideredCount" Decode.int
        |> required "evaluationCount" Decode.int
        |> required "matchedCount" Decode.int
        |> required "time" Decode.string

Is there an advantage to preferring the lambdas in that case?

@avh4 the advantage is that it's harder to swap arguments by mistake.

The code below is perfectly valid, looks good, but it's wrong.

import Json.Decode.Pipeline exposing (decode, required)

decodeEngineResult : Decoder EngineResult
decodeEngineResult =
    decode EngineResult
        |> required "evaluationCount" Decode.int
        |> required "consideredCount" Decode.int
        |> required "matchedCount" Decode.int
        |> required "time" Decode.string

The first two fields are swapped, but it's really hard to tell.

Worse, the same problem will happen if we reorder the attributes in the definition of EngineResult.

[avh4]

(for reference) Here's a version of the original example that actually compiles:

type alias Model =
    { floor : Maybe Floor
    , selectedObjects : List Id
    }


type Floor
    = Floor


type Object
    = Object


type Id
    = Id


type Direction
    = Direction

editingFloor_present : Floor -> Floor
editingFloor_present a =
    a


selectedObjects : Model -> List Object
selectedObjects _ =
    []


floor_objects : Floor -> List Object
floor_objects _ =
    []


object_idOf : Object -> Id
object_idOf _ =
    Id


objectsOperation_nearest : Direction -> Object -> List Object -> Maybe Object
objectsOperation_nearest _ _ _ =
    Nothing


x : Direction -> Model -> Model
x direction model =
    model.floor
        |> Maybe.map editingFloor_present
        |> Maybe.andThen
            (\floor ->
                List.head (selectedObjects model)
                    |> Maybe.andThen
                        (\primarySelected ->
                            objectsOperation_nearest direction primarySelected (floor_objects floor)
                                |> Maybe.map
                                    (\object ->
                                        { model
                                            | selectedObjects =
                                                List.map object_idOf [ object ]
                                        }
                                    )
                        )
            )
        |> Maybe.withDefault model

[avh4]

Here's a possible alternative to the originally-posted code:

x : Direction -> Model -> Model
x direction model =
    let
        primarySelected =
            selectedObjects model
                |> List.head

        floorObjects =
            model.floor
                |> Maybe.map editingFloor_present
                |> Maybe.map floor_objects
                |> Maybe.withDefault []

        nearestFloorObject primarySelected =
            objectsOperation_nearest direction primarySelected floorObjects
    in
        { model
            | selectedObjects =
                primarySelected
                    |> Maybe.andThen nearestFloorObject
                    |> Maybe.map object_idOf
                    |> Maybe.map List.singleton
                    |> Maybe.withDefault model.selectedObjects
        }

[jinjor]

This refactoring makes sense a lot. Thank you :)

One point I care about is that the benefit of Html.Lazy.lazy decreases because re-assigning record property (selectedObjects) will lose the original record's reference.

[jligeza]

Wouldn't this be better?

a
  |> \x -> x
  |> \y -> y
  |> \z -> z

I have a pipe with a single small lamba in the middle of it, and it increases the indentation for no reason, what makes the pipe harder to read.

[timjs]

I just encountered that the experimental version (0.7.0) formats the following code

checkPattern Unpack preTy >>= \preEnv ->
checkPattern Unpack postTy >>= \postEnv ->
checkFlow (Env.merge preEnv env) body >>= \bodyEnv ->
checkSubset postEnv.values bodyEnv.values

like this

checkPattern Unpack preTy
    >>= (\preEnv ->
            checkPattern Unpack postTy
                >>= (\postEnv ->
                        checkFlow (Env.merge preEnv env) body
                            >>= (\bodyEnv ->
                                    checkSubset postEnv.values bodyEnv.values
                                )
                    )
        )

(Yes, I use bind sometimes 😉)

I can live with the indentation, because I think it makes scoping explicit, but I'm not sure about two things:

1. Why are lines after a bind indented two levels?
2. Do we need to add parens for the lambda?

Btw: when using andThen the parens are needed and the formatting uses one indent level at a time.

After fixing the double indentation (1):

checkPattern Unpack preTy
    >>= (\preEnv ->
        checkPattern Unpack postTy
            >>= (\postEnv ->
                checkFlow (Env.merge preEnv env) body
                    >>= (\bodyEnv ->
                        checkSubset postEnv.values bodyEnv.values
                        )
                )
        )

and removing parens (2):

checkPattern Unpack preTy
    >>= \preEnv ->
        checkPattern Unpack postTy
            >>= \postEnv ->
                checkFlow (Env.merge preEnv env) body
                    >>= \bodyEnv ->
                        checkSubset postEnv.values bodyEnv.values

What do you think? I prefer the parens-less version, it looks less cluttered and they are actually redundant. But removing the double indentation already improves a lot!

Edit: the code looks even better when we remove the indentation before the bind operator. You can perfectly see where each lambda variable is bound! This formatting obviously has consequences for a lot of other operators, like (|>) though...

checkPattern Unpack preTy
>>= \preEnv ->
    checkPattern Unpack postTy
    >>= \postEnv ->
        checkFlow (Env.merge preEnv env) body
        >>= \bodyEnv ->
            checkSubset postEnv.values bodyEnv.values

[xarvh]

Has there been any more thought on this?

I think it's a major bug with elm-format.

This is ugly, but at least is readable and maintainable:

mapDecoder : Decoder Map
mapDecoder =
        (field "name" <| Decode.string) |> Decode.andThen (\name ->
        (field "author" <| Decode.string) |> Decode.andThen (\author ->
        (field "mainBases" <| listOfTilesDecoder) |> Decode.andThen (\mainBases ->
        (field "smallBases" <| listOfTilesDecoder) |> Decode.andThen (\smallBases ->
        (field "wallTiles" <| listOfTilesDecoder) |> Decode.andThen (\wallTiles ->
          Decode.succeed
            { name = name
            , author = author
            , mainBases = mainBases
            , smallBases = smallBases
            , wallTiles = wallTiles
            }
        )))))

But the elm-format output is:

    (field "name" <| Decode.string)
        |> Decode.andThen
            (\name ->
                (field "author" <| Decode.string)
                    |> Decode.andThen
                        (\author ->
                            (field "mainBases" <| listOfTilesDecoder)
                                |> Decode.andThen
                                    (\mainBases ->
                                        (field "smallBases" <| listOfTilesDecoder)
                                            |> Decode.andThen
                                                (\smallBases ->
                                                    (field "wallTiles" <| listOfTilesDecoder)
                                                        |> Decode.andThen
                                                            (\wallTiles ->
                                                                Decode.succeed
                                                                    { name = name
                                                                    , author = author
                                                                    , mainBases = mainBases
                                                                    , smallBases = smallBases
                                                                    , wallTiles = wallTiles
                                                                    }
                                                            )
                                                )
                                    )
                        )
            )

Which is not maintainable by a human.

[avh4]

From what I'm currently seeing in the community, I think the current recommended practice for the last example would be:

mapDecoder : Decoder Map
mapDecoder =
    Decode.map5 Map
        (field "name" Decode.string)
        (field "author" Decode.string)
        (field "mainBases" listOfTilesDecoder)
        (field "smallBases" listOfTilesDecoder)
        (field "wallTiles" listOfTilesDecoder)

Though that still has the issue ghost mentioned #352 (comment)

[xarvh]

Yup. I'd really like to avoid argument swaps, especially since it can happen by just reordering the attributes in the record.

[avh4]

For completeness, there are multiple ways to help avoid mixing up the attributes:

• add nesting to the code, as shown previously in this thread
• define types that prevent mixing up: type MainBases = MainBases (List Tile), (field "mainBases" <| Decode.map MainBases listofTilesDecoder)
• divide the code so there's less room for error: (field "tiles" tilesDecoder) (so map.tiles contains mainBases, smallBases, wallTiles)

In what cases should nesting be preferred over other alternatives? I think defining more types is the traditional functional-programming solution to this problem--is it common for people to do that in Elm?

[rtfeldman]

Here are some points to add to the discussion:

1. Since the library came out, I have heard about the concern that people can swap arguments in decode pipeline and cause bugs.
2. Nearly everyone I talk to who does any JSON decoding uses that library to do it.
3. Even with so many people using the library, in practice I do not hear people complaining that they have the pain point where they swapped the arguments and it caused bugs for them.

I understand that this can happen, but I don't think it's fair to say that it's a "major bug with elm-format" that elm-format doesn't accommodate a technique that would let you avoid using one of the most popular libraries in the Elm ecosystem, out of concern for a problem that isn't reported to be a significant problem in practice.