[Rd] [External] Re: New pipe operator

Gabor Grothendieck ggrothend|eck @end|ng |rom gm@||@com
Sun Dec 6 18:32:31 CET 2020 

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-tierney using 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.sarkar using gmail.com> wrote:
> >>
> >> On Fri, Dec 4, 2020 at 7:35 PM Duncan Murdoch <murdoch.duncan using 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.duncan using 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 using r-project.org mailing list
> >>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>>>
> >>>> ______________________________________________
> >>>> R-devel using r-project.org mailing list
> >>>> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>>>
> >>>
> >>> ______________________________________________
> >>> R-devel using r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
> >> ______________________________________________
> >> R-devel using r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> > ______________________________________________
> > R-devel using 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-tierney using uiowa.edu
> Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu
> ______________________________________________
> R-devel using 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

More information about the R-devel mailing list