[Rd] should base R have a piping operator ?

[Duncan Murdoch]

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