Argument order of `andMap`

[yardsale8]

I find the argument order of andMap curious. Most maps have the function(s) preceding the data, which facilitates piping with maps.

xs 
 |> func1
 |> map func2
 |> func3

The current argument order means including andMap in a pipe is awkward.

xs 
 |> f
 |> \d -> andMap d gs
 |> h

It seems to me that this function would be more useful with the arguments in the opposite order.

data
|> f
|> andMap gs
|> h

What are the advantages of current implementation? Would it be possible to switch the order?

Motivation for the change

I frequently find myself performing programming origami by unfolding data, applying a sequence of functions to each component, then folding the data back together. Swapping the argument order of andMap facilitates this style of programming.

data
  |> unfold
  |> andMap doStuff
  |> fold

For example, suppose I am making a string representation of a record of type {x : Int, y : Float}. The brute force solution

makeStr r =
[ "{"
, r |> .x |> String.fromInt
, ", "
, r |> .y |> String.fromFloat
, "}"
] |> String.join " "

involves two similar, but necessarily different, pipes. Using the origami approach, this refactors into

-- helpers
xToStr = .x << String.fromInt
yToStr = .y << String.fromFloat
wrapRecord s = "{" ++ s ++ "}"

makeStr r =
  r
  |> repeat 2                --unfold
  |> andMap [xToStr, yToStr] --doStuff
  |> String.join ", "        --fold
  |> wrapRecord

[pzp1997]

There's some history to this decision, see https://github.com/elm-community/list-extra/commit/31d0fc1027d46aca925f32995a0ef24303dd74c5 and https://groups.google.com/forum/#!topic/elm-dev/gdh55ZOi1Fs.

I think it is worth pointing out that there is no argument order that will satisfy everyone's needs. While you listed several examples in your issue that would be cleaner if the order of the arguments was flipped, there are also plenty of examples where flipping the argument order would degrade code quality. The decision over argument order ultimately comes down to which cases come up more frequently in practice, conventions as defined by similar existing functions, the cost of switching for existing code, etc.