R devel - Oct 2019 - should base R have a piping operator ?

> 
> On 7 Oct 2019, at 13:47, Duncan Murdoch <murdoch.duncan at 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.

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


	[[alternative HTML version deleted]]

On 07/10/2019 8:38 a.m., Lionel Henry wrote:
>>
>> On 7 Oct 2019, at 13:47, Duncan Murdoch <murdoch.duncan at gmail.com
>> <mailto:murdoch.duncan at 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
>

> On 7 Oct 2019, at 15:36, Duncan Murdoch <murdoch.duncan at gmail.com>
wrote:
> 
>  I think that could be done after parsing at run-time, as described in my
earlier message.
Good point.

> 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.
Just a hypothetical native pipe for which the parser would automatically
wrap the arguments in srcref-carrying braces. Then we get step-debugging
of pipelines in all editors.


Best,
Lionel
	[[alternative HTML version deleted]]