From deep@y@n@@@rk@r @end|ng |rom gm@||@com  Mon Dec  7 16:59:46 2020
From: deep@y@n@@@rk@r @end|ng |rom gm@||@com (Deepayan Sarkar)
Date: Mon, 7 Dec 2020 21:29:46 +0530
Subject: [Rd] New pipe operator
In-Reply-To: <CAP01uRneP4C-TjMQ7EOmP_D==yuqU2zWsp8SW1R5Yg8q3ZFeYg@mail.gmail.com>
References: <e55c2093-0bb5-5f9b-5521-0ca8bdf35953@gmail.com>
 <CALyqOb8c1hHOSaMV+fqXTwpeOsP--KJ_t-oeqMYYafVXeNpqZg@mail.gmail.com>
 <7586e034-e287-0970-6480-f82d747b5445@gmail.com>
 <CADfFDC7bT58_+52uvmpHuMMQRNbbmqV3_7t_fc4sgJ_Esw=xag@mail.gmail.com>
 <CAJmOi+PO_8XDC23=rT=pQ76ENL=gx2V-41ax2fHSVs87xURcEA@mail.gmail.com>
 <CAP01uRkkd3jOjvaS9JgKYCD1KA83HfzCd+MQSv_2aYJPgcOmSQ@mail.gmail.com>
 <CAP01uRkPcbCBRGwAzKM=W19Ohh-zDGwZH8gM7=A-sK2rRaQxaQ@mail.gmail.com>
 <CAD4oTHFBY4rBhiRsJUkA6jwD2YWaxPMz2OZDOqSvHfv6A7DZPg@mail.gmail.com>
 <CAP01uRmTYna1nM+ugELHrCqLjfWuWwHSfE4cvqoaq2537sHpAw@mail.gmail.com>
 <CAD4oTHHFWkiirncPRWngY+_k9HcB=8zo7VdXAONXQoXdNhKzDA@mail.gmail.com>
 <7e28d84a-f6d0-1e18-c131-163650e7cd75@gmail.com>
 <CAP01uRkCpLQ0uwJgFdTFTNG+80C+F1hn=TnQqRS2Z-nFuU5MmA@mail.gmail.com>
 <CADfFDC74ostfecs5mhOznSXEedGBA=_78SiNTfysz5B8JU=YUQ@mail.gmail.com>
 <CAP01uRneP4C-TjMQ7EOmP_D==yuqU2zWsp8SW1R5Yg8q3ZFeYg@mail.gmail.com>
Message-ID: <CADfFDC6dj2z_DH5KdReWYmbjsqn=tKaxC3WpheH=NWQr2VfrDA@mail.gmail.com>

On Mon, Dec 7, 2020 at 9:23 PM Gabor Grothendieck
<ggrothendieck at gmail.com> wrote:
>
> One could examine how magrittr works as a reference implementation if
> there is a question on how something should function.  It's in
> widespread use and seems to work well.

Yes, but it has many inconsistencies (including for the example I
gave). Do you want a magrittr clone, or do you want consistency? It's
OK to want either, but I don't think you can get both.

What we actually end up with is another matter, depending on many
other factors. I was just trying to understand your consistency
argument.

-Deepayan

> On Mon, Dec 7, 2020 at 10:20 AM Deepayan Sarkar
> <deepayan.sarkar at gmail.com> wrote:
> >
> > On Mon, Dec 7, 2020 at 6:53 PM Gabor Grothendieck
> > <ggrothendieck at gmail.com> wrote:
> > >
> > > On Mon, Dec 7, 2020 at 5:41 AM Duncan Murdoch <murdoch.duncan at gmail.com> wrote:
> > > > I agree it's all about call expressions, but they aren't all being
> > > > treated equally:
> > > >
> > > > x |> f(...)
> > > >
> > > > expands to f(x, ...), while
> > > >
> > > > x |> `function`(...)
> > > >
> > > > expands to `function`(...)(x).  This is an exception to the rule for
> > > > other calls, but I think it's a justified one.
> > >
> > > This admitted inconsistency is justified by what?  No argument has been
> > > presented.  The justification seems to be implicitly driven by implementation
> > > concerns at the expense of usability and language consistency.
> >
> > Sorry if I have missed something, but is your consistency argument
> > basically that if
> >
> > foo <- function(x) x + 1
> >
> > then
> >
> > x |> foo
> > x |> function(x) x + 1
> >
> > should both work the same? Suppose it did. Would you then be OK if
> >
> > x |> foo()
> >
> > no longer worked as it does now, and produced foo()(x) instead of foo(x)?
> >
> > If you are not OK with that and want to retain the current behaviour,
> > what would you want to happen with the following?
> >
> > bar <- function(x) function(n) rnorm(n, mean = x)
> >
> > 10 |> bar(runif(1))() # works 'as expected' ~ bar(runif(1))(10)
> > 10 |> bar(runif(1)) # currently bar(10, runif(1))
> >
> > both of which you probably want. But then
> >
> > baz <-  bar(runif(1))
> > 10 |> baz
> >
> > (not currently allowed) will not be the same as what you would want from
> >
> > 10 |> bar(runif(1))
> >
> > which leads to a different kind of inconsistency, doesn't it?
> >
> > -Deepayan
>
>
>
> --
> Statistics & Software Consulting
> GKX Group, GKX Associates Inc.
> tel: 1-877-GKX-GROUP
> email: ggrothendieck at gmail.com



[Rd] New pipe operator
Deepayan Sarkar