> Gabriel Becker
> on Tue, 8 Dec 2020 17:09:57 -0800 writes:
> Of course you can, but the ability to do something via R
> code and the ability to do them by wrapping the invocation
> of R are not similar terms of convenience, IMO.
> I say that as someone who routinely
Hi,
I'm a data scientist who routinely uses R in my day-to-day work, for tasks
such as cleaning and transforming data, exploratory data analysis, etc.
This includes frequent use of the pipe operator from the magrittr and dplyr
libraries, %>%. So, I was pleased to hear about the recent work on a
n
I'm not a pipe user, so I may be overlooking some issue, but wouldn't simply
putting identity() on the last line solve your main problem?
### Example 1 ###
my_data_frame_1 %>%
filter(some_conditions_1) %>%
inner_join(my_data_frame_2, by = some_columns_1) %>%
group_by(some_columns_2) %>%
The requirement for operators at the end of the line comes from the
interactive nature of R. If you type
my_data_frame_1
how could R know that you are not done, and are planning to type the
rest of the expression
%>% filter(some_conditions_1)
...
before it should consider t
On Wed, Dec 9, 2020 at 4:03 AM Timothy Goodman wrote:
> But the bigger issue happens when I want to re-run just *part* of the
> pipeline.
Insert one of the following into the pipeline. It does not require that you
edit any lines. It only involves inserting a line.
print %>%
{ str(.); . } %
On 08-12-2020 12:46, Gabor Grothendieck wrote:
Duncan Murdoch:
I agree it's all about call expressions, but they aren't all being
treated equally:
x |> f(...)
expands to f(x, ...), while
x |> `function`(...)
expands to `function`(...)(x). This is an exception to the rule for
Yes, this
You might be interested in this blog post by Michael Barrowman:
https://michaelbarrowman.co.uk/post/the-new-base-pipe/
He does some timing comparisons, and the current R-devel implementations
of |> and \() do quite well.
Duncan Murdoch
On 06/12/2020 4:42 a.m., Jan Gorecki wrote:
Luke,
When
On 09/12/2020 9:55 a.m., Jan van der Laan wrote:
I think only allowing functions on the right hand side (e.g. only the |>
operator and not the |:>) would be enough to handle most cases and seems
easier to reason about. The limitations of that can easily be worked
around using existing functiona
On 09-12-2020 16:20, Duncan Murdoch wrote:
On 09/12/2020 9:55 a.m., Jan van der Laan wrote:
I think only allowing functions on the right hand side (e.g. only the |>
operator and not the |:>) would be enough to handle most cases and seems
easier to reason about. The limitations of that can
On 09/12/2020 10:42 a.m., Jan van der Laan wrote:
On 09-12-2020 16:20, Duncan Murdoch wrote:
On 09/12/2020 9:55 a.m., Jan van der Laan wrote:
I think only allowing functions on the right hand side (e.g. only the |>
operator and not the |:>) would be enough to handle most cases and seems
e
On Wed, Dec 9, 2020 at 10:08 AM Duncan Murdoch wrote:
>
> You might be interested in this blog post by Michael Barrowman:
>
> https://michaelbarrowman.co.uk/post/the-new-base-pipe/
>
> He does some timing comparisons, and the current R-devel implementations
> of |> and \() do quite well.
It does
On Wed, Dec 9, 2020 at 8:26 AM Gabor Grothendieck
wrote:
> On Wed, Dec 9, 2020 at 10:08 AM Duncan Murdoch
> wrote:
> >
> > You might be interested in this blog post by Michael Barrowman:
> >
> > https://michaelbarrowman.co.uk/post/the-new-base-pipe/
> >
> > He does some timing comparisons, and t
On Wed, Dec 9, 2020 at 12:36 PM Gabriel Becker wrote:
> I mean, I think the bizarro pipe was a pretty clever piece of work. I was
> impressed by what John did there, but I don't really know what you're
> suggesting here. As you say, the bizarro pipe works now without any changes
> and you're we
> On 9 Dec 2020, at 16:20 , Duncan Murdoch wrote:
>
> To me curry(mean, na.rm = TRUE)(x) looks a lot more complicated than mean(x,
> na.rm = TRUE), especially since it has the additional risk that users can
> define their own function called "curry".
Not to mention that it would make people
On 9 December 2020 at 09:49, Martin Maechler wrote:
| Also, R allows the user to remove their own home directory, it
| should also allow to get a .libPaths() which contains nothing compulsory
| but R's own .Library {as only that can contain 'base' !}
That would be a very nice-to-have feature! Bu
Since `+` is already a function we could do regular piping to change this code:
mtcars %>%
ggplot(aes(x=wt, y=mpg)) +
geom_point()
to this:
mtcars %>%
ggplot(aes(x=wt, y=mpg)) %>%
`+`(geom_point())
Further we can write wrapper functions like:
p_geom_point <- function(x,...) {
x + geo
Looks like Sergio Oller took your ambitious approach:
https://github.com/zeehio/ggpipe. It hasn't been updated since 2017, so
there may be some new things in ggplot2 that aren't there yet.
Duncan Murdoch
On 09/12/2020 2:16 p.m., Greg Snow wrote:
Since `+` is already a function we could do re
If I type my_data_frame_1 and press Enter (or Ctrl+Enter to execute the
command in the Notebook environment I'm using) I certainly *would* expect R
to treat it as a complete statement.
But what I'm talking about is a different case, where I highlight a
multi-line statement in my notebook:
my_
I agree with Duncan that the right solution is to wrap the pipe
expression with parentheses. Having the parser treat newlines
differently based on whether the session is interactive, or on what
type of operator happens to follow a newline, feels like a pretty big
can of worms.
I think this (or som
Another option is https://github.com/hadley/ggplot1 🤣
Hadley
On Wed, Dec 9, 2020 at 1:24 PM Duncan Murdoch wrote:
>
> Looks like Sergio Oller took your ambitious approach:
> https://github.com/zeehio/ggpipe. It hasn't been updated since 2017, so
> there may be some new things in ggplot2 that are
On 09/12/2020 2:33 p.m., Timothy Goodman wrote:
If I type my_data_frame_1 and press Enter (or Ctrl+Enter to execute the
command in the Notebook environment I'm using) I certainly *would*
expect R to treat it as a complete statement.
But what I'm talking about is a different case, where I highl
FWIW there is previous discussion of this in a twitter thread from May:
https://twitter.com/bolkerb/status/1258542150620332039
at the end I suggested defining something like .__END <- identity() as a
pipe-ender.
On 12/9/20 2:58 PM, Kevin Ushey wrote:
I agree with Duncan that the right solu
Regarding special treatment for |>, isn't it getting special treatment
anyway, because it's implemented as a syntax transformation from x |> f(y)
to f(x, y), rather than as an operator?
That said, the point about wanting a block of code submitted line-by-line
to work the same as a block of code su
Definitely support the idea that if this kind of trickery is going to
happen that it be confined to some particular IDE/environment or some
particular submission protocol. I don't want it to happen in my ESS
session please ... I'd rather deal with the parentheses.
On 12/9/20 3:45 PM, Timothy
On 09/12/2020 3:45 p.m., Timothy Goodman wrote:
Regarding special treatment for |>, isn't it getting special treatment
anyway, because it's implemented as a syntax transformation from x |>
f(y) to f(x, y), rather than as an operator?
That's different. Currently |> is parsed just like any othe
Many languages allow a final backslash (“\”) character to allow an
expression to span multiple lines, and I’ve often wished for this in R,
particularly to allow me to put `else` on a separate line at the
top-level. It would also allow alignment of infix operators like the new
pipe operator `|>` at
On Wed, Dec 9, 2020 at 1:03 PM Duncan Murdoch
wrote: Then I could run any number of lines with pipes at the
> > start and no special character at the end, and have it treated as a
> > single pipeline. I suppose that'd need to be a feature offered by the
> > environment (RStudio's RNotebooks in
I'm thrilled to hear it! Thank you!
- Tim
P.S. I re-added the r-devel list, since Kevin's reply was sent just to me,
but I thought there might be others interested in knowing about those work
items. (I hope that's OK, email-etiquette-wise.)
On Wed, Dec 9, 2020 at 1:10 PM Kevin Ushey wrote:
>
When I am debugging a function with code like
x <- f1(x)
x <- f2(x)
result <- f3(x)
I will often slip a line like '.GlobalEnv$tmp1 <- x' between the first two
lines and '.GlobalEnv$tmp2 <- x' between the last two lines and look at the
intermediate results, 'tmp1' and 'tmp2' in the globa
29 matches
Mail list logo
