Folks might be wondering, why this change?

Well, for elm version 0.18, the consensus appears to have been removing the the Backticks as an infix operator, in favor of Pipe-lining via the Pipe Operator because Backticks were redundant with the Pipe Operator, easily confused with single quotes depending on specific font used , and not as user friendly or popular as Pipe-lining (many languages nowadays support Pipe-lining).

andThen & Task.onError

The functions affected are the andThen functions and the Task.onError function, but in order to do so, the function’s argument order from elm version 0.17 had to be changed in elm version 0.18, since the andThen function and most functions supporting Backticks, `f` , were written with the first operation to be initiated in the first argument position and the callback in the second position in line with the natural order of their use and specifically, with andThen , in keeping with its namesake.

Below we compare a generic Backtick Operator supported function in elm version 0.17 to a generic Pipeline-friendly function in elm version 0.18 to understand what has exactly changed. Then we show how to roll our own for functions that do not support Pipe-lining.

Legend f: a -> ( a -> b ) -> c -- elm version 0.17 first_fx = result

second_fx = callback

elm version 0.17



f first_fx second_fx -- normal function order first_fx `f` second_fx -- Backticks infix Operator

You could do the following in elm version 0.17, but this would not make much logical sense nor would it be easy to read if there were more than one pipe in the Pipeline.

second_fx

|> andThen first_fx --elm 0.17 (makes no sense)

We can easily see that for functions which have their callback, or second operation as the second argument prevents the Pipe Operator from being used practically or sensibly.

Therefore, for elm version 0.18, andThen had its arguments switched accordingly.

elm version 0.18

f:( a -> b) -> a -> c



f second_fx first_fx -- arguments order switched first_fx

|> f second_fx -- Pipeline Pattern (no Backticks)



It looks like there will be more functions which will support Pipe-lining.

Rolling Your Own Pipeline Friendly Function

In the meantime, if there are any functions that do not support Pipe-lining and you want to provide this feature you can always use the flip function to do so.

For example, in elm version 0.17, Result.andThen does not support Pipe-lining as discussed above. However if flip is used as shown below:

piped_andThen x y =

flip Result.andThen x y

this new wrapped andThen for elm version 0.17, piped_andThen , now supports Pipe-lining as shown below:

toFloatnCheckBetweenZeroAnd100 str =

|> String.toInt str

|> piped_andThen (\x -> String.toFloat (toString x))

|> piped_andThen isFloatBetweenZeroAnd100

-- elm-repl Output:

-- Ok 240 : Result String Float

-- Note: This code snippet supports elm v0.17 not v0.18

where isFloatBetweenZeroAnd100 is

isFloatBetweenZeroAnd100: Float -> Result String Float

isFloatBetweenZeroAnd100 num =

if num >= 0.0 && num <= 100.0 then

Ok (num * 10)

else

Err “Not a number between 0.0 and 100.0”

We can see what flip does by just looking at its function annotation.

flip: (a -> b -> c) -> (b -> a -> c)

Hello Pipeline!

Recap

All that changed was the order of arguments the actual body of the function definitions did not change nor need not change to support Pipe-lining.

So, we now have Pipe-lining straight out of the box for andThen and Task.onError, expect to see more functions support Pipe-lining down the road, in the meantime roll your own. If you want to kick the tires, with a Result.andThen example using elm version 0.18, you can grab the source from here.

Let me know what you think about Pipe-lining.

Do you like Pipe-lining? Or absolutely hate it?

If you liked this, click the💚 below so other people will see this here on Medium.

Links of Interest