On 12/7/20 11:09 PM, Gabriel Becker wrote:
On Mon, Dec 7, 2020 at 11:05 AM Kevin Ushey <kevinus...@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
<ggrothendi...@gmail.com> wrote:
On Mon, Dec 7, 2020 at 12:54 PM Duncan Murdoch <murdoch.dun...@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@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
[[alternative HTML version deleted]]
______________________________________________
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
