The construct utils::head is not that common but bare functions are very common and to make it harder to use the common case so that the uncommon case is slightly easier is not desirable. Also it is trivial to write this which does work: mtcars %>% (utils::head) On Sat, Dec 5, 2020 at 11:59 AM Hugh Parsonage <hugh.parsonage at gmail.com> 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 at gmail.com> wrote: > > > > On Fri, Dec 4, 2020 at 7:35 PM Duncan Murdoch <murdoch.duncan at 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 at 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 at r-project.org mailing list > > > >> https://stat.ethz.ch/mailman/listinfo/r-devel > > > > > > > > ______________________________________________ > > > > R-devel at r-project.org mailing list > > > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > > > > > > > ______________________________________________ > > > R-devel at r-project.org mailing list > > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > ______________________________________________ > > R-devel at r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > ______________________________________________ > R-devel at 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
The :: is a case that we worked to get right with wrapr dot-pipe. I shared notes
on this S3/S4 pipe in the R journal
https://journal.r-project.org/archive/2018/RJ-2018-042/index.html
library(magrittr)
packageVersion("magrittr")
# [1] ?2.0.1?
5 %>% base::sin
# Error in .::base : unused argument (sin)
library(wrapr)
5 %.>% base::sin
# [1] -0.9589243
On Dec 5, 2020, at 10:08 AM, Gabor Grothendieck <ggrothendieck at
gmail.com<mailto:ggrothendieck at gmail.com>> wrote:
The construct utils::head is not that common but bare functions are
very common and to make it harder to use the common case so that
the uncommon case is slightly easier is not desirable.
Also it is trivial to write this which does work:
mtcars %>% (utils::head)
On Sat, Dec 5, 2020 at 11:59 AM Hugh Parsonage <hugh.parsonage at
gmail.com<mailto:hugh.parsonage at gmail.com>> 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 at
gmail.com<mailto:deepayan.sarkar at gmail.com>> wrote:
On Fri, Dec 4, 2020 at 7:35 PM Duncan Murdoch <murdoch.duncan at
gmail.com<mailto:murdoch.duncan at 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 at
gmail.com<mailto:murdoch.duncan at 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 at r-project.org<mailto:R-devel at r-project.org> mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel at r-project.org<mailto:R-devel at r-project.org> mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel at r-project.org<mailto:R-devel at r-project.org> mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel at r-project.org<mailto:R-devel at r-project.org> mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel at r-project.org<mailto:R-devel at 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<http://gmail.com>
______________________________________________
R-devel at r-project.org<mailto:R-devel at r-project.org> mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[[alternative HTML version deleted]]
I think the real issue here is that functions are supposed to be first class objects in R or are supposed to be and |> would break that if if is possible to write function(x) x + 1 on the RHS but not foo (assuming foo was defined as that function). I don't think getting experience with using it can change that inconsistency which seems serious to me and needs to be addressed even if it complicates the implementation since it drives to the heart of what R is. On Sat, Dec 5, 2020 at 1:08 PM Gabor Grothendieck <ggrothendieck at gmail.com> wrote:> > The construct utils::head is not that common but bare functions are > very common and to make it harder to use the common case so that > the uncommon case is slightly easier is not desirable. > > Also it is trivial to write this which does work: > > mtcars %>% (utils::head) > > On Sat, Dec 5, 2020 at 11:59 AM Hugh Parsonage <hugh.parsonage at gmail.com> 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 at gmail.com> wrote: > > > > > > On Fri, Dec 4, 2020 at 7:35 PM Duncan Murdoch <murdoch.duncan at 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 at 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 at r-project.org mailing list > > > > >> https://stat.ethz.ch/mailman/listinfo/r-devel > > > > > > > > > > ______________________________________________ > > > > > R-devel at r-project.org mailing list > > > > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > > > > > > > > > > ______________________________________________ > > > > R-devel at r-project.org mailing list > > > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > > > ______________________________________________ > > > R-devel at r-project.org mailing list > > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > ______________________________________________ > > R-devel at 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-- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com