Am 04.12.20 um 15:05 schrieb Duncan Murdoch:
> 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.
Thank you for this example. I agree but think that the new base R pipe
might trigger some initial confusion as well:
mtcars |> function(x) dim(x)[1L]
#> [1] 32
mtcars |> nrow
#> Error: The pipe operator requires a function call or an anonymous
function expression as RHS
The RHS evaluates to the same thing in both cases (bar attributes and
environments), but only the anonymous variant is supported. I admit that
I haven't used %>% before; maybe the above discrepancy is less
irritating for those who have. The error message is clear though!
That said, I think the code is very readable when piping explicitly into
an anonymous function and I also prefer
mtcars |> nrow()
over mtcars |> nrow, because we are visibly calling something.
IMO, readability is lost when using the cryptic short-hand notation
mtcars |> \(x) dim(x)[1L]
which really only saves 7 letters.
> 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 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 guess "_" as a placeholder would be difficult to implement precisely
because it currently is a syntax error.
Best regards,
Sebastian Meyer
> 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
