;
> >> Alternately, you can ask that when used in such a pipeline that the user
> >> call all other arguments using names like data=whatever,
> >> mapping=aes(whatever) so no other args need to be adjusted by position.
> >>
> >> But all this is academ
ata=whatever, mapping=aes(whatever) so no
other args need to be adjusted by position.
But all this is academic and I concede will likely not be done. I can live with
the plus signs.
-Original Message-
From: Duncan Murdoch
Sent: Sunday, December 6, 2020 2:50 PM
To: Avi Gross ; 'r-
ith the plus signs.
>
>
> -Original Message-
> From: Duncan Murdoch
> Sent: Sunday, December 6, 2020 2:50 PM
> To: Avi Gross ; 'r-devel'
> Subject: Re: [Rd] New pipe operator and gg plotz
>
> Hadley's answer (#7 here:
> https://community.rstudio
> On 9 Dec 2020, at 16:20 , Duncan Murdoch wrote:
>
> To me curry(mean, na.rm = TRUE)(x) looks a lot more complicated than mean(x,
> na.rm = TRUE), especially since it has the additional risk that users can
> define their own function called "curry".
Not to mention that it would make people
On 09/12/2020 10:42 a.m., Jan van der Laan wrote:
On 09-12-2020 16:20, Duncan Murdoch wrote:
On 09/12/2020 9:55 a.m., Jan van der Laan wrote:
I think only allowing functions on the right hand side (e.g. only the |>
operator and not the |:>) would be enough to handle most cases and seems
e
On 09-12-2020 16:20, Duncan Murdoch wrote:
On 09/12/2020 9:55 a.m., Jan van der Laan wrote:
I think only allowing functions on the right hand side (e.g. only the |>
operator and not the |:>) would be enough to handle most cases and seems
easier to reason about. The limitations of that can
On 09/12/2020 9:55 a.m., Jan van der Laan wrote:
I think only allowing functions on the right hand side (e.g. only the |>
operator and not the |:>) would be enough to handle most cases and seems
easier to reason about. The limitations of that can easily be worked
around using existing functiona
On 08-12-2020 12:46, Gabor Grothendieck wrote:
Duncan Murdoch:
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
Yes, this
arser change
- and the use of a reserved-word placeholder also isn't possible as-is
If there's some way to try those things out, it would be great.
cheers
Mark
Mark Bravington
CSIRO Marine Lab
Hobart
Australia
From: Duncan Murdoch
Sent: Wednesday
_' and body 'expr'
#2. Construct a call() to that function
#3. Do the call
f <- function( `_PIPE_`) NULL
body( f) <- expr
environment( f) <- parent.frame() # or something... yes these details are
almost certainly wrong
expr2 <- substitute( f( `_PIPE_`)) # or something...
eval
;- function( `_PIPE_`) NULL
> > body( f) <- expr
> > environment( f) <- parent.frame() # or something... yes these details are
> > almost certainly wrong
> > expr2 <- substitute( f( `_PIPE_`)) # or something...
> > eval.parent( expr2) # or somethi
I just wanted to pipe in here (HA HA) to say that I agree with Kevin.
I've never loved the complicated magrittr rule (which has personally
tripped me up a couple of times) and I think the compact inline
function syntax provides a more general solution. It is a bit more
typing, and it will require a
Duncan Murdoch:
> 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
Yes, this is the problem. It is trying to handl
Hi Denes,
On Mon, Dec 7, 2020 at 2:52 PM Dénes Tóth wrote:
>
>
> This gave me the idea that naming the arguments can be used to skip the
> placeholder issue:
>
> "funny" |> sub(pattern = "f", replacement = "b")
>
> Of course this breaks if the maintainer changes the order of the
> function argum
On 12/7/20 11:09 PM, Gabriel Becker wrote:
On Mon, Dec 7, 2020 at 11:05 AM Kevin Ushey wrote:
IMHO the use of anonymous functions is a very clean solution to the
placeholder problem, and the shorthand lambda syntax makes it much
more ergonomic to use. Pipe implementations that crawl the RHS
On Mon, Dec 7, 2020 at 11:05 AM Kevin Ushey wrote:
> IMHO the use of anonymous functions is a very clean solution to the
> placeholder problem, and the shorthand lambda syntax makes it much
> more ergonomic to use. Pipe implementations that crawl the RHS for
> usages of `.` are going to be more e
On Mon, Dec 7, 2020 at 10:35 AM Gabor Grothendieck
wrote:
> On Mon, Dec 7, 2020 at 12:54 PM Duncan Murdoch
> wrote:
> > An advantage of the current implementation is that it's simple and easy
> > to understand. Once you make it a user-modifiable binary operator,
> > things will go kind of nuts.
On Mon, Dec 7, 2020 at 2:02 PM Kevin Ushey wrote:
>
> IMHO the use of anonymous functions is a very clean solution to the
> placeholder problem, and the shorthand lambda syntax makes it much
> more ergonomic to use. Pipe implementations that crawl the RHS for
> usages of `.` are going to be more e
IMHO the use of anonymous functions is a very clean solution to the
placeholder problem, and the shorthand lambda syntax makes it much
more ergonomic to use. Pipe implementations that crawl the RHS for
usages of `.` are going to be more expensive than the alternatives. It
is nice that the `|>` oper
On Mon, Dec 7, 2020 at 12:54 PM Duncan Murdoch wrote:
> An advantage of the current implementation is that it's simple and easy
> to understand. Once you make it a user-modifiable binary operator,
> things will go kind of nuts.
>
> For example, I doubt if there are many users of magrittr's pipe w
On 07/12/2020 12:09 p.m., Peter Dalgaard wrote:
On 7 Dec 2020, at 17:35 , Duncan Murdoch wrote:
On 07/12/2020 11:18 a.m., peter dalgaard wrote:
Hmm,
I feel a bit bad coming late to this, but I think I am beginning to side with those who want
"... |> head" to work. And yes, that has to hap
> On 7 Dec 2020, at 17:35 , Duncan Murdoch wrote:
>
> On 07/12/2020 11:18 a.m., peter dalgaard wrote:
>> Hmm,
>> I feel a bit bad coming late to this, but I think I am beginning to side
>> with those who want "... |> head" to work. And yes, that has to happen at
>> the expense of |> head().
On 07/12/2020 11:18 a.m., peter dalgaard wrote:
Hmm,
I feel a bit bad coming late to this, but I think I am beginning to side with those who want
"... |> head" to work. And yes, that has to happen at the expense of |> head().
Just curious, how would you express head(df, 10)? Currently it is
Hmm,
I feel a bit bad coming late to this, but I think I am beginning to side with
those who want "... |> head" to work. And yes, that has to happen at the
expense of |> head().
As I think it was Gabor points out, the current structure goes down a
nonstandard evaluation route, which may be di
On Mon, Dec 7, 2020 at 9:23 PM Gabor Grothendieck
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 exam
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.
On Mon, Dec 7, 2020 at 10:20 AM Deepayan Sarkar
wrote:
>
> On Mon, Dec 7, 2020 at 6:53 PM Gabor Grothendieck
> wrote:
> >
>
On Mon, Dec 7, 2020 at 6:53 PM Gabor Grothendieck
wrote:
>
> On Mon, Dec 7, 2020 at 5:41 AM Duncan Murdoch
> 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`(...)
> >
On Mon, Dec 7, 2020 at 5:41 AM Duncan Murdoch 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 cal
On 06/12/2020 9:23 p.m., Gabriel Becker wrote:
Hi Gabor,
On Sun, Dec 6, 2020 at 3:22 PM Gabor Grothendieck
wrote:
I understand very well that it is implemented at the syntax level;
however, in any case the implementation is irrelevant to the principles.
Here a similar example to the one I ga
e call
f <- function( `_PIPE_`) NULL
body( f) <- expr
environment( f) <- parent.frame() # or something... yes these details are
almost certainly wrong
expr2 <- substitute( f( `_PIPE_`)) # or something...
eval.parent( expr2) # or something...
}
cheers
Mark
Mark Bravington
This is really irrelevant.
On Sun, Dec 6, 2020 at 9:23 PM Gabriel Becker wrote:
>
> Hi Gabor,
>
> On Sun, Dec 6, 2020 at 3:22 PM Gabor Grothendieck
> wrote:
>>
>> I understand very well that it is implemented at the syntax level;
>> however, in any case the implementation is irrelevant to the p
Hi Gabor,
On Sun, Dec 6, 2020 at 3:22 PM Gabor Grothendieck
wrote:
> I understand very well that it is implemented at the syntax level;
> however, in any case the implementation is irrelevant to the principles.
>
> Here a similar example to the one I gave before but this time written out:
>
> Th
so no
other args need to be adjusted by position.
But all this is academic and I concede will likely not be done. I can live with
the plus signs.
-Original Message-
From: Duncan Murdoch
Sent: Sunday, December 6, 2020 2:50 PM
To: Avi Gross ; 'r-devel'
Subject: Re: [Rd] New pi
eval.parent( expr2) # or something...
}
cheers
Mark
Mark Bravington
CSIRO Marine Lab
Hobart
Australia
From: R-devel on behalf of Gabor Grothendieck
Sent: Monday, 7 December 2020 10:21
To: Gabriel Becker
Cc: r-devel@r-project.org
Subject: Re: [Rd] New
I understand very well that it is implemented at the syntax level;
however, in any case the implementation is irrelevant to the principles.
Here a similar example to the one I gave before but this time written out:
This works:
3 |> function(x) x + 1
but this does not:
foo <- function(x) x
Hi Gabor,
On Sun, Dec 6, 2020 at 12:52 PM Gabor Grothendieck
wrote:
> I think the real issue here is that functions are supposed to be
> first class objects in R
> or are supposed to be and |> would break that if if is possible
> to write function(x) x + 1 on the RHS but not foo (assuming foo
>
I think the real issue here is that functions are supposed to be
first class objects in R
or are supposed to be and |> would break that if if is possible
to write function(x) x + 1 on the RHS but not foo (assuming foo
was defined as that function).
I don't think getting experience with using it ca
to
gradually migrate back closer to the mainstream?
-Original Message-
From: R-devel On Behalf Of Rui Barradas
Sent: Sunday, December 6, 2020 2:51 AM
To: Gregory Warnes ; Abby Spurdle
Cc: r-devel
Subject: Re: [Rd] New pipe operator
Hello,
If Hilbert liked beer, I like "pipe"
closer to the mainstream?
-Original Message-
From: R-devel On Behalf Of Rui Barradas
Sent: Sunday, December 6, 2020 2:51 AM
To: Gregory Warnes ; Abby Spurdle
Cc: r-devel
Subject: Re: [Rd] New pipe operator
Hello,
If Hilbert liked beer, I like "pipe".
More seriously, a new additi
make things clear or we might as well code in binary.
-Original Message-
From: R-devel On Behalf Of Rui Barradas
Sent: Sunday, December 6, 2020 2:51 AM
To: Gregory Warnes ; Abby Spurdle
Cc: r-devel
Subject: Re: [Rd] New pipe operator
Hello,
If Hilbert liked beer, I like "pipe"
lowchart!
Time to go do something useful.
-Original Message-
From: R-devel On Behalf Of Hiroaki Yutani
Sent: Saturday, December 5, 2020 10:29 PM
To: Abby Spurdle
Cc: r-devel
Subject: Re: [Rd] New pipe operator
It is common practice to call |> as pipe (or pipeline operator) amon
Hello,
If Hilbert liked beer, I like "pipe".
More seriously, a new addition like this one is going to cause problems
yet unknown. But it's a good idea to have a pipe operator available. As
someone used to magrittr's data pipelines, I will play with this base
one before making up my mind. I do
It is common practice to call |> as pipe (or pipeline operator) among
many languages
including ones that recently introduced it as an experimental feature.
Pipeline is a
common feature for functional programming, not just for "data pipeline."
F#:
https://docs.microsoft.com/en-us/dotnet/fsharp
If we’re being mathematically pedantic, the “pipe” operator is actually
function composition.
That being said, pipes are a simple and well-known idiom. While being less
than mathematically exact, it seems a reasonable label for the (very
useful) behavior.
On Sat, Dec 5, 2020 at 9:43 PM Abby Spu
> This is a good addition
I can't understand why so many people are calling this a "pipe".
Pipes connect processes, via their I/O streams.
Arguably, a more general interpretation would include sockets and files.
https://en.wikipedia.org/wiki/Pipeline_(Unix)
https://en.wikipedia.org/wiki/Named_pip
The :: is a case that we worked to get right with wrapr dot-pipe. I shared
notes on this S3/S4 pipe in the R journal
https://journal.r-project.org/archive/2018/RJ-2018-042/index.html
library(magrittr)
packageVersion("magrittr")
# [1] ‘2.0.1’
5 %>% base::sin
# Error in .::base : unused argument (
The construct utils::head is not that common but bare functions are
very common and to make it harder to use the common case so that
the uncommon case is slightly easier is not desirable.
Also it is trivial to write this which does work:
mtcars %>% (utils::head)
On Sat, Dec 5, 2020 at 11:59 AM
I'm surprised by the aversion to
mtcars |> nrow
over
mtcars |> nrow()
and I think the decision to disallow the former should be
reconsidered. The pipe operator is only going to be used when the rhs
is a function, so there is no ambiguity with omitting the parentheses.
If it's disallowed, it be
On 04/12/2020 12:06 p.m., Deepayan Sarkar wrote:
On Fri, Dec 4, 2020 at 7:35 PM Duncan Murdoch wrote:
On 04/12/2020 8:13 a.m., Hiroaki Yutani wrote:
Error: function '::' not supported in RHS call of a pipe
To me, this error looks much more friendly than magrittr's error.
Some of them got
On Fri, Dec 4, 2020 at 7:35 PM Duncan Murdoch wrote:
>
> On 04/12/2020 8:13 a.m., Hiroaki Yutani wrote:
> >> Error: function '::' not supported in RHS call of a pipe
> >
> > To me, this error looks much more friendly than magrittr's error.
> > Some of them got too used to specify functions witho
Am 04.12.20 um 15:05 schrieb Duncan Murdoch:
> On 04/12/2020 8:13 a.m., Hiroaki Yutani wrote:
>>> Error: function '::' not supported in RHS call of a pipe
>>
>> To me, this error looks much more friendly than magrittr's error.
>> Some of them got too used to specify functions without (). This
>>
On 12/4/20 3:05 PM, Duncan Murdoch wrote:
...
It's tempting to suggest it should allow something like
mtcars |> subset(cyl == 4) |> lm(mpg ~ disp, data = .)
which would be expanded to something equivalent to the other versions:
but that makes it quite a bit more complicated. (Maybe _ or
On 04/12/2020 8:13 a.m., Hiroaki Yutani wrote:
Error: function '::' not supported in RHS call of a pipe
To me, this error looks much more friendly than magrittr's error.
Some of them got too used to specify functions without (). This
is OK until they use `::`, but when they need to use it, it
> Error: function '::' not supported in RHS call of a pipe
To me, this error looks much more friendly than magrittr's error.
Some of them got too used to specify functions without (). This
is OK until they use `::`, but when they need to use it, it takes
hours to figure out why
mtcars %>% base::
Just saw this on the R-devel news:
R now provides a simple native pipe syntax ‘|>’ as well as a shorthand
notation for creating functions, e.g. ‘\(x) x + 1’ is parsed as
‘function(x) x + 1’. The pipe implementation as a syntax transformation
was motivated by suggestions from Jim Hester and Li
55 matches
Mail list logo
