From ||one| @end|ng |rom r@tud|o@com  Mon Oct  7 14:38:19 2019
From: ||one| @end|ng |rom r@tud|o@com (Lionel Henry)
Date: Mon, 7 Oct 2019 14:38:19 +0200
Subject: [Rd] should base R have a piping operator ?
In-Reply-To: <056d3c18-4d2b-0456-3e9f-6b496d733816@gmail.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>
Message-ID: <4126370A-8386-406C-AD94-B8A99E2AE52E@rstudio.com>

> 
> 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]]



[Rd] should base R have a piping operator ?
Lionel Henry