The following gives an error. 1 |> `+`(2) ## Error: function '+' is not supported in RHS call of a pipe
1 |> `+`() ## Error: function '+' is not supported in RHS call of a pipe but this does work: 1 |> (`+`)(2) ## [1] 3 1 |> (`+`)() ## [1] 1 The error message suggests that this was intentional. It isn't mentioned in ?"|>" On Sat, Dec 5, 2020 at 1:19 PM <luke-tier...@uiowa.edu> wrote: > > We went back and forth on this several times. The key advantage of > requiring parentheses is to keep things simple and consistent. Let's > get some experience with that. If experience shows requiring > parentheses creates too many issues then we can add the option of > dropping them later (with special handling of :: and :::). It's easier > to add flexibility and complexity than to restrict it after the fact. > > Best, > > luke > > On Sat, 5 Dec 2020, Hugh Parsonage wrote: > > > I'm surprised by the aversion to > > > > mtcars |> nrow > > > > over > > > > mtcars |> nrow() > > > > and I think the decision to disallow the former should be > > reconsidered. The pipe operator is only going to be used when the rhs > > is a function, so there is no ambiguity with omitting the parentheses. > > If it's disallowed, it becomes inconsistent with other treatments like > > sapply(mtcars, typeof) where sapply(mtcars, typeof()) would just be > > noise. I'm not sure why this decision was taken > > > > If the only issue is with the double (and triple) colon operator, then > > ideally `mtcars |> base::head` should resolve to `base::head(mtcars)` > > -- in other words, demote the precedence of |> > > > > Obviously (looking at the R-Syntax branch) this decision was > > considered, put into place, then dropped, but I can't see why > > precisely. > > > > Best, > > > > > > Hugh. > > > > > > > > > > > > > > > > On Sat, 5 Dec 2020 at 04:07, Deepayan Sarkar <deepayan.sar...@gmail.com> > > wrote: > >> > >> On Fri, Dec 4, 2020 at 7:35 PM Duncan Murdoch <murdoch.dun...@gmail.com> > >> wrote: > >>> > >>> On 04/12/2020 8:13 a.m., Hiroaki Yutani wrote: > >>>>> Error: function '::' not supported in RHS call of a pipe > >>>> > >>>> To me, this error looks much more friendly than magrittr's error. > >>>> Some of them got too used to specify functions without (). This > >>>> is OK until they use `::`, but when they need to use it, it takes > >>>> hours to figure out why > >>>> > >>>> mtcars %>% base::head > >>>> #> Error in .::base : unused argument (head) > >>>> > >>>> won't work but > >>>> > >>>> mtcars %>% head > >>>> > >>>> works. I think this is a too harsh lesson for ordinary R users to > >>>> learn `::` is a function. I've been wanting for magrittr to drop the > >>>> support for a function name without () to avoid this confusion, > >>>> so I would very much welcome the new pipe operator's behavior. > >>>> Thank you all the developers who implemented this! > >>> > >>> I agree, it's an improvement on the corresponding magrittr error. > >>> > >>> I think the semantics of not evaluating the RHS, but treating the pipe > >>> as purely syntactical is a good decision. > >>> > >>> I'm not sure I like the recommended way to pipe into a particular > >>> argument: > >>> > >>> mtcars |> subset(cyl == 4) |> \(d) lm(mpg ~ disp, data = d) > >>> > >>> or > >>> > >>> mtcars |> subset(cyl == 4) |> function(d) lm(mpg ~ disp, data = d) > >>> > >>> both of which are equivalent to > >>> > >>> mtcars |> subset(cyl == 4) |> (function(d) lm(mpg ~ disp, data = d))() > >>> > >>> It's tempting to suggest it should allow something like > >>> > >>> mtcars |> subset(cyl == 4) |> lm(mpg ~ disp, data = .) > >> > >> Which is really not that far off from > >> > >> mtcars |> subset(cyl == 4) |> \(.) lm(mpg ~ disp, data = .) > >> > >> once you get used to it. > >> > >> One consequence of the implementation is that it's not clear how > >> multiple occurrences of the placeholder would be interpreted. With > >> magrittr, > >> > >> sort(runif(10)) %>% ecdf(.)(.) > >> ## [1] 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 > >> > >> This is probably what you would expect, if you expect it to work at all, > >> and not > >> > >> ecdf(sort(runif(10)))(sort(runif(10))) > >> > >> There would be no such ambiguity with anonymous functions > >> > >> sort(runif(10)) |> \(.) ecdf(.)(.) > >> > >> -Deepayan > >> > >>> which would be expanded to something equivalent to the other versions: > >>> but that makes it quite a bit more complicated. (Maybe _ or \. should > >>> be used instead of ., since those are not legal variable names.) > >>> > >>> I don't think there should be an attempt to copy magrittr's special > >>> casing of how . is used in determining whether to also include the > >>> previous value as first argument. > >>> > >>> Duncan Murdoch > >>> > >>> > >>>> > >>>> Best, > >>>> Hiroaki Yutani > >>>> > >>>> 2020年12月4日(金) 20:51 Duncan Murdoch <murdoch.dun...@gmail.com>: > >>>>> > >>>>> Just saw this on the R-devel news: > >>>>> > >>>>> > >>>>> R now provides a simple native pipe syntax ‘|>’ as well as a shorthand > >>>>> notation for creating functions, e.g. ‘\(x) x + 1’ is parsed as > >>>>> ‘function(x) x + 1’. The pipe implementation as a syntax transformation > >>>>> was motivated by suggestions from Jim Hester and Lionel Henry. These > >>>>> features are experimental and may change prior to release. > >>>>> > >>>>> > >>>>> This is a good addition; by using "|>" instead of "%>%" there should be > >>>>> a chance to get operator precedence right. That said, the ?Syntax help > >>>>> topic hasn't been updated, so I'm not sure where it fits in. > >>>>> > >>>>> There are some choices that take a little getting used to: > >>>>> > >>>>> > mtcars |> head > >>>>> Error: The pipe operator requires a function call or an anonymous > >>>>> function expression as RHS > >>>>> > >>>>> (I need to say mtcars |> head() instead.) This sometimes leads to error > >>>>> messages that are somewhat confusing: > >>>>> > >>>>> > mtcars |> magrittr::debug_pipe |> head > >>>>> Error: function '::' not supported in RHS call of a pipe > >>>>> > >>>>> but > >>>>> > >>>>> mtcars |> magrittr::debug_pipe() |> head() > >>>>> > >>>>> works. > >>>>> > >>>>> Overall, I think this is a great addition, though it's going to be > >>>>> disruptive for a while. > >>>>> > >>>>> Duncan Murdoch > >>>>> > >>>>> ______________________________________________ > >>>>> R-devel@r-project.org mailing list > >>>>> https://stat.ethz.ch/mailman/listinfo/r-devel > >>>> > >>>> ______________________________________________ > >>>> R-devel@r-project.org mailing list > >>>> https://stat.ethz.ch/mailman/listinfo/r-devel > >>>> > >>> > >>> ______________________________________________ > >>> R-devel@r-project.org mailing list > >>> https://stat.ethz.ch/mailman/listinfo/r-devel > >> > >> ______________________________________________ > >> R-devel@r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/r-devel > > > > ______________________________________________ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > -- > Luke Tierney > Ralph E. Wareham Professor of Mathematical Sciences > University of Iowa Phone: 319-335-3386 > Department of Statistics and Fax: 319-335-3017 > Actuarial Science > 241 Schaeffer Hall email: luke-tier...@uiowa.edu > Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
