For andThen in particular, there is a cool trick: (&) : (a -> Decoder b) -> Decoder a -> Decoder b (&>) = flip andThen
On Friday, June 3, 2016 at 2:39:09 AM UTC+2, Ian Mackenzie wrote: > > I realize that the window for large breaking changes to the Elm language > and libraries is rapidly closing (if it's not closed already), and perhaps > the whole backtick-vs-pipeline discussion has been beaten to death already, > but I've been thinking for a while that we might just be able to have our > cake and eat it too if we changed the way backticks work so that > a `foo` b > was equivalent to > foo b a > instead of the current > foo a b > > If at the same time Task.andThen etc. had their argument orders flipped > (as previously discussed at length), > andThen : (a -> Task x b) -> Task x a -> Task x b > then you could continue using andThen as an infix operator just the same > as always (since in this case the two changes would cancel out), but you > could now *also* use pipelining with |> in the natural way; to take the > example from the Task documentation, > succeed 2 `andThen` (\n -> succeed (n + 2)) > would be equivalent to > succeed 2 |> andThen (\n -> succeed (n + 2)) > or the 'plain' version > andThen (\n -> succeed (n + 2)) (succeed 2) > (except for perhaps associativity issues - I confess I haven't worked that > through). > > It seems to me this could resolve the conflict between providing > "pipeline-friendly" and "backtick-friendly" functions since the same rule > (put the data structure last!) would work in both cases. In fact, I suspect > *all* infix operators could benefit from the flipped-argument treatment, > so for instance > x / y > would map to > (/) y x > Then you could do things like > List.map ((/) 2) [2, 4, 6] == [1, 2, 3] > which is currently valid syntax but returns [1, 0.5, 0.333] instead; if > you happened to love backticks you could even do > [2, 4, 6] `List.map` ((/) 2) == [1, 2, 3] > which, if nothing else, should look pretty familiar to those coming from > traditional object-oriented languages. > > Thoughts? Are there some nasty unintended consequences I've missed, or > some Elm associativity or other syntax rules that make this impractical? Or > is it just too late to make this disruptive a change? I apologize if this > has been proposed before - I looked through the old conversations about > backticks vs pipelines and couldn't find any mention of this particular > solution. > > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
