One advantage of the new pipe operator over magrittr's is that the former
works with substitute().
> f <- function(x, xlab=deparse1(substitute(x))) paste(sep="", xlab, ": ",
paste(collapse=", ",x))
> 2^(1:4) |> f()
[1] "2^(1:4): 2, 4, 8, 16"
> 2^(1:4) %>% f()
[1] ".: 2, 4, 8, 16"
This is because the new one is at the parser level, so f() sees an ordinary
function call.
> dput(quote(2^(1:4) |> f()))
f(2^(1:4))
On Mon, Dec 7, 2020 at 10:35 AM Therneau, Terry M., Ph.D. via R-devel <
r-devel@r-project.org> wrote:
> Luke,
> Mostly an aside. I think that pipes are a good addition, and it is
> clear that you and
> other R-core thought through many of the details. Congratulations on
> what appears to be
> solid work. I've used Unix since '79, so it is almost guarranteed that I
> like the basic
> idiom, and I expect to make use of it. Users who think that pipes -- or
> any other code --
> is so clear that comments are superfluous is no reflection on R core, and
> also a bit of a
> hobby horse for me.
>
> I am a bit bemused by the flood of change suggestions, before people have
> had a chance to
> fully exercise the new code. I'd suggest waiting several months, or a
> year, before major
> updates, straight up bugs excepted. The same advice holds when moving
> into a new house.
> One experience with the survival package has been that most new ideas
> have been
> implemented locally, and we run with them for half a year before
> submission to CRAN. I've
> had a few "really great" modifications that, thankfully, were never
> inflicted on the rest
> of the R community.
>
> Terry T.
>
> On 12/7/20 11:26 AM, luke-tier...@uiowa.edu wrote:
> > I don't disagree in principle, but the reality is users want shortcuts
> > and as a result various packages, in particular tidyverse, have been
> > providing them. Mostly based on formulas, mostly with significant
> > issues since formulas weren't designed for this, and mostly
> > incompatible (tidyverse ones are compatible within tidyverse but not
> > with others). And of course none work in sapply or lapply. Providing a
> > shorthand in base may help to improve this. You don't have to use it
> > if you don't want to, and you can establish coding standards that
> > disallow it if you like.
> >
> > Best,
> >
> > luke
> >
> > On Mon, 7 Dec 2020, Therneau, Terry M., Ph.D. via R-devel wrote:
> >
> >> “The shorthand form \(x) x + 1 is parsed as function(x) x + 1. It may
> be helpful in
> >> making code containing simple function expressions more readable.”
> >>
> >> Color me unimpressed.
> >> Over the decades I've seen several "who can write the shortest code"
> threads: in
> >> Fortran, in C, in Splus, ... The same old idea that "short" is a
> synonym for either
> >> elegant, readable, or efficient is now being recylced in the
> tidyverse. The truth is
> >> that "short" is actually an antonym for all of these things, at least
> for anyone else
> >> reading the code; or for the original coder 30-60 minutes after the
> "clever" lines were
> >> written. Minimal use of the spacebar and/or the return key isn't
> usually held up as a
> >> goal, but creeps into many practiioner's code as well.
> >>
> >> People are excited by replacing "function(" with "\("? Really? Are
> people typing code
> >> with their thumbs?
> >> I am ambivalent about pipes: I think it is a great concept, but too
> many of my
> >> colleagues think that using pipes = no need for any comments.
> >>
> >> As time goes on, I find my goal is to make my code less compact and
> more readable.
> >> Every bug fix or new feature in the survival package now adds more
> lines of comments or
> >> other documentation than lines of code. If I have to puzzle out what a
> line does, what
> >> about the poor sod who inherits the maintainance?
> >>
> >>
> >>
> >
>
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
