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
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:
>
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
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 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
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
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
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
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
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
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_
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(.); . } %
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
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) %>%
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
15 matches
Mail list logo
