From deep@y@n@@@rk@r @end|ng |rom gm@||@com  Mon Dec  7 16:20:09 2020
From: deep@y@n@@@rk@r @end|ng |rom gm@||@com (Deepayan Sarkar)
Date: Mon, 7 Dec 2020 20:50:09 +0530
Subject: [Rd] New pipe operator
In-Reply-To: <CAP01uRkCpLQ0uwJgFdTFTNG+80C+F1hn=TnQqRS2Z-nFuU5MmA@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>
Message-ID: <CADfFDC74ostfecs5mhOznSXEedGBA=_78SiNTfysz5B8JU=YUQ@mail.gmail.com>

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



[Rd] New pipe operator
Deepayan Sarkar