[Rd] [External] Re: New pipe operator
Avi Gross
@v|gro@@ @end|ng |rom ver|zon@net
Sat Dec 5 03:56:29 CET 2020
Luke and others,
Can anyone comment on how this new pipe operator will interoperate with existing pipe methods or packages like the tidyverse that currently do things using them?
What differences might it make for efficiency? For example, making an anonymous function just so you can call another function and pass along the results to somewhere other than the first argument sounds like extra overhead. But the anonymous function does provide some interesting scenarios that allow things like a sort of tee functionality that may print/graph a mid-stream result as well as pass it along the pipeline or do amusing things like apply multiple steps to the data and perhaps concatenate some of the results in the output. Of course, that can be done now with a non-anonymous function.
Perhaps we should name one version (or the other) a pipette or a pipe dream 😉
The name "pipe" feels better in the new version as "|>" has the UNIX pipe symbol "|" in it.
-----Original Message-----
From: R-devel <r-devel-bounces using r-project.org> On Behalf Of luke-tierney using uiowa.edu
Sent: Friday, December 4, 2020 9:11 PM
To: Duncan Murdoch <murdoch.duncan using gmail.com>
Cc: r-devel using r-project.org
Subject: Re: [Rd] [External] Re: New pipe operator
On Sat, 5 Dec 2020, Duncan Murdoch wrote:
> On 04/12/2020 2:26 p.m., luke-tierney using uiowa.edu wrote:
>> On Fri, 4 Dec 2020, Dénes Tóth wrote:
>>
>>>
>>> On 12/4/20 3:05 PM, Duncan Murdoch wrote:
>>>> ...
>>>>
>>>> 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 support the idea of using an underscore (_) as the placeholder symbol.
>>
>> I strongly oppose adding a placeholder. Allowing for an optional
>> placeholder significantly complicates both implementing and
>> explaining the semantics. For a simple syntax transformation to be
>> viable it would also require some restrictions, such as only allowing
>> a placeholder as a top level argument and only once. Checking that
>> these restrictions are met, and accurately signaling when they are
>> not with reasonable error messages, is essentially an unsolvable
>> problem given R's semantics.
>
> I don't think you read my suggestion, but that's okay: you're
> maintaining it, not me.
I thought I did but maybe I missed something. You are right that supporting a placeholder makes things a lot more complicated. For being able to easily recognize the non-standard cases _ is better than . but for me at least not by much.
We did try a number of variations; the code is in the R-syntax branch.
At the root of that branch are two .md files with some notes as of around useR20. Once things settle down I may update those and look into turning them into a blog post.
Best,
luke
>
> Duncan Murdoch
>
>>
>> The case where the LHS is to be passed as something other than the
>> first argument is unusual. For me, having that case stand out by
>> using a function expression makes it much easier to see and so makes
>> the code easier to understand. As a wearer of progressive bifocals
>> and someone whose screen is not always free of small dust particles,
>> having to spot the non-standard pipe stages by seeing a placeholder,
>> especially a . placeholder, is be a bug, not a feature.
>>
>> Best,
>>
>> luke
>>
>>> Syntactic sugars work the the best if 1) they require less
>>> keystrokes and/or
>>> 2) are easier to read compared to the "normal" syntax, and 3) can
>>> not lead to unexpected bugs (which is a major problem with the
>>> magrittr pipe). Using '_'
>>> fulfills all of these criteria since '_' can not clash with any
>>> variable in the environment.
>>>
>>> Denes
>>>
>>> ______________________________________________
>>> 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
Scanned by McAfee and confirmed virus-free.
Find out more here: https://bit.ly/2zCJMrO
More information about the R-devel
mailing list