Closed tripartio closed 1 year ago
I'm generally no longer a big fan of functions like compose()
, because I think the vast majority of readers are better served by just explicitly composing the functions (which is particularly easy with the pipe).
I have only recently discovered the
compose
adverb, so my apologies in advance if a similar feature request has already been made (but I did not find anything when I searched past issues).First of all, I fully understand and agree with the decision that
compose
should compose its input functions from right-to-left as in standard mathematics. I consider this a difficult decision because most tidyverse users would probably prefer a left-to-right implementation, but I agree that the mathematical standard should take precedence.That said, a right-to-left compose is counterintuitive for tidyverse users like myself who prefer left-to-right pipes.
compose(..., .dir = "forward")
is an awkward function signature when that is what I would use every time. So, my simple solution is that I have a tiny function in my personal R utilities file:So, this works for me, but I would like to propose to generalize this (or a similar) solution for purrr.
The quick and simple solution would be to add a similar
compose_pipe
function (or some other name that might be decided) to purrr that defaults to a left-to-right compose. My argument for adding such a function is:compose
. This is simply becausecompose_pipe
uses the intuitive pipe order that tidyverse programmers prefer (and which might very well become predominant among R programmers in general, now that the pipe has become incorporated into base R).compose_pipe(...)
is more compact than typingcompose(..., .dir = 'forward')
, which would normally require an extra line.compose_pipe
is perfectly intuitive to programmers who learn about the notion of compose yet who do not know about the mathematical compose function. That is, for those who do not know the mathematical compose function, a function named "compose a pipe" probably makes more sense for a function that combines functions than simply "compose". This is just a hunch, though.compose_pipe
function involves no change whatsoever to the public-facing interface of the existing compose function, so it would have almost no effect on existing code. Indeed, it would have no effect at all if not for my next point...If this suggestion is accepted, then I would go further and then suggest that
compose_pipe
should become the reference implementation and that it should callcompose
, rather than my current workaround above. This is because if, as I suspect, most programmers would usecompose_pipe
rather thancompose
, then it would make sense to makecompose_pipe
the base call so that it could execute faster, rather than vice versa.If not for the last suggestion, my suggestion for
compose_pipe
could have been a simple pull request. But ifcompose_pipe
would become the base function from which the currentcompose
function would be called, then the change would be not quite as trivial (it should still be quite easy, but it would require careful testing).