[R/S-PLUS] [EXTERNAL] Re: [External] anonymous functions
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 at 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-tierney at 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 at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel