From murdoch@dunc@n @end|ng |rom gm@||@com  Mon Oct  7 15:36:03 2019
From: murdoch@dunc@n @end|ng |rom gm@||@com (Duncan Murdoch)
Date: Mon, 7 Oct 2019 09:36:03 -0400
Subject: [Rd] should base R have a piping operator ?
In-Reply-To: <4126370A-8386-406C-AD94-B8A99E2AE52E@rstudio.com>
References: <CAEKh8uidcEWA4tzmkpQxpF=q7r93qjf-HtiWLfbT91TFGOSzFQ@mail.gmail.com>
 <CAGpovd2jxxWBUxPhMAR6ZPw1+UQzK7BzJVtps10cMBSp=EUdHQ@mail.gmail.com>
 <CALEXWq0ZvGeTbeq-AeYTSTcTwR-TR+gGczqQhWupzB2h0wa+zg@mail.gmail.com>
 <CAGpovd29V3rXSyB_SMBnbKfb3dzAFPF66ck9iU6XPB_+bS+8WQ@mail.gmail.com>
 <CAEKh8ugr0FNryRVmM64pBPxjP=4xLrC0T2OsUD27mSASAyHpVQ@mail.gmail.com>
 <CAD4oTHHgSUr5TfLaTHxAM94E-Sqw9bW6gON7KdW324VEr524Lw@mail.gmail.com>
 <95648642-FCC6-49BE-93D9-8872172946E6@rstudio.com>
 <056d3c18-4d2b-0456-3e9f-6b496d733816@gmail.com>
 <4126370A-8386-406C-AD94-B8A99E2AE52E@rstudio.com>
Message-ID: <032922f2-37a7-5197-04e8-b9ac51990e91@gmail.com>

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
>



[Rd] should base R have a piping operator ?
Duncan Murdoch