On 12/7/20 11:09 PM, Gabriel Becker wrote:> On Mon, Dec 7, 2020 at 11:05 AM Kevin Ushey <kevinushey at gmail.com>
wrote:
>
>> IMHO the use of anonymous functions is a very clean solution to the
>> placeholder problem, and the shorthand lambda syntax makes it much
>> more ergonomic to use. Pipe implementations that crawl the RHS for
>> usages of `.` are going to be more expensive than the alternatives. It
>> is nice that the `|>` operator is effectively the same as a regular
R
>> function call, and given the identical semantics could then also be
>> reasoned about the same way regular R function calls are.
>>
>
> I agree. That said, one thing that maybe could be done, though I'm not
> super convinced its needed, is make a "curry-stuffed pipe", where
something
> like
>
> LHS |^pipearg^> RHS(arg1 = 5, arg3 = 7)
>
> Would parse to
>
> RHS(pipearg = LHS, arg1 = 5, arg3 = 7)
>
This gave me the idea that naming the arguments can be used to skip the
placeholder issue:
"funny" |> sub(pattern = "f", replacement =
"b")
Of course this breaks if the maintainer changes the order of the
function arguments (which is not a nice practice but happens).
An option could be to allow for missing argument in the first position,
but this might add further undesired complexity, so probably not worth
the effort:
"funny" |> sub(x =, "f", "b")
So basically the parsing rule would be:
LHS |> RHS(arg=, ...) -> RHS(arg=LHS, ...)
>
> (Assuming we could get the parser to handle |^bla^> correctly)
>
> For argument position issues would be sufficient. For more complicated
> expressions, e.g., those that would use the placeholder multiple times or
> inside compound expressions, requiring anonymous functions seems quite
> reasonable to me. And honestly, while I kind of like it, I'm not sure
if
> that "stuffed pipe" expression (assuming we could get the parser
to capture
> it correctly) reads to me as nicer than the following, anyway.
>
> LHS |> \(x) RHS(arg1 = 5, pipearg = x, arg3 = 7)
>
> ~G
>
>>
>> I also agree usages of the `.` placeholder can make the code more
>> challenging to read, since understanding the behavior of a piped
>> expression then requires scouring the RHS for usages of `.`, which can
>> be challenging in dense code. Piping to an anonymous function makes
>> the intent clear to the reader: the programmer is likely piping to an
>> anonymous function because they care where the argument is used in the
>> call, and so the reader of code should be aware of that.
>>
>> Best,
>> Kevin
>>
>>
>>
>> On Mon, Dec 7, 2020 at 10:35 AM Gabor Grothendieck
>> <ggrothendieck at gmail.com> wrote:
>>>
>>> On Mon, Dec 7, 2020 at 12:54 PM Duncan Murdoch <murdoch.duncan
at gmail.com>
>> wrote:
>>>> An advantage of the current implementation is that it's
simple and easy
>>>> to understand. Once you make it a user-modifiable binary
operator,
>>>> things will go kind of nuts.
>>>>
>>>> For example, I doubt if there are many users of magrittr's
pipe who
>>>> really understand its subtleties, e.g. the example in
Luke's paper
>> where
>>>> 1 %>% c(., 2) gives c(1,2), but 1 %>% c(c(.), 2) gives
c(1, 1, 2). (And
>>>> I could add 1 %>% c(c(.), 2, .) and 1 %>% c(c(.), 2, . +
2) to
>>>> continue the fun.)
>>>
>>> The rule is not so complicated. Automatic insertion is done unless
>>> you use dot in the top level function or if you surround it with
>>> {...}. It really makes sense since if you use gsub(pattern,
>>> replacement, .) then surely you don't want automatic insertion
and if
>>> you surround it with { ... } then you are explicitly telling it not
>>> to.
>>>
>>> Assuming the existence of placeholders a possible simplification
would
>>> be to NOT do automatic insertion if { ... } is used and to use it
>>> otherwise although personally having used it for some time I find
the
>>> existing rule in magrittr generally does what you want.
>>>
>>> ______________________________________________
>>> 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
>>
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>