On 07/10/2019 8:38 a.m., Lionel Henry wrote:
On 7 Oct 2019, at 13:47, Duncan Murdoch <murdoch.dun...@gmail.com
<mailto:murdoch.dun...@gmail.com>> wrote:
On 07/10/2019 4:22 a.m., Lionel Henry wrote:
Hi Gabe,
There is another way the pipe could go into base R that could not be
done in package space and has the potential to mitigate some pretty
serious downsides to the pipes relating to debugging
I assume you're thinking about the large stack trace of the magrittr
pipe? You don't need a parser transformation to solve this problem
though, the pipe could be implemented as a regular function with a
very limited impact on the stack. And if implemented as a SPECIALSXP,
it would be completely invisible. We've been planning to rewrite %>%
to fix the performance and the stack print, it's just low priority.
I don't know what Gabe had in mind, but the downside to pipes that I
see is that they are single statements. I'd like the debugger to be
able to single step through one stage at a time. I'd like to be able
to set a breakpoint on line 3 in
a %>%
b %>%
c %>%
d
and be able to examine the intermediate result of evaluating b before
piping it into c. (Or maybe that's off by one: maybe I'd prefer to
examine the inputs to d if I put a breakpoint there. I'd have to try
it to find out which feels more natural.)
In order to place a breakpoint on line 3, I think you'll need to wrap
`c()` in curly braces and insert a `browser()` call. And at that point
you're changing the semantics of `c()` and you'll need to manually
write the placeholder for the input:
a() |>
b() |>
{ browser(); c(.) } |>
d()
I don't see any way around this. I guess it could be done behind the
scenes by the IDE when a breakpoint is set though. Note that this
doesn't require any changes to the parser and already works with the
magrittr pipe.
Yes, I was hoping this would happen behind the scenes. I agree that the
parser doesn't need to be changed, but the IDE would need to break up
the statement into 3 or more equivalent statements for this to work with
no changes to core R. I think that could be done after parsing at
run-time, as described in my earlier message.
Duncan Murdoch
P.S. Were you just using |> to save typing, or is there a proposal to
add a new operator to the language? That would need parser changes.
Then there's the issue of continuing to step-debug through the
pipeline. This could be achieved by parsing `a |> b()` as `{a} |>
{b()}`. so that each sub-expression carries source references. In
general, there are metaprogramming patterns that would be made easier
if calls to `function` or `if` always had a body wrapped in `{`. It is
too late to change historical operators but maybe it makes sense for
newer ones?
Lionel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
