On 06/12/2020 8:22 p.m., Bravington, Mark (Data61, Hobart) wrote:
Seems like this *could* be a good thing, and thanks to R core for considering
it. But, FWIW:
- I agree with Gabor G that consistency of "syntax" should be paramount here.
Enough problems have been caused by earlier superficial
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
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 Sat, Dec 5, 2020 at 1:19 PM wrote:
> Let's get some experience
Here is my last SO post using dplyr rewritten to use R 4.1 devel. Seems
not too bad. Was able to work around the placeholder for gsub by specifying
the arg names and used \(...)... elsewhere. This does not address the
inconsiste
Or, keeping dplyr but with R-devel pipe and function shorthand:
DF <- "myfile.csv" %>%
readLines() |>
\(.) gsub(r'{(c\(.*?\)|integer\(0\))}', r'{"\1"}', .) |>
\(.) read.csv(text = .) |>
mutate(across(2:3, \(col) lapply(col, \(x) eval(parse(text = x)
Using named arguments to redir
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`(...)
> >
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 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
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 10:11 AM wrote:
> Or, keeping dplyr but with R-devel pipe and function shorthand:
>
> DF <- "myfile.csv" %>%
> readLines() |>
> \(.) gsub(r'{(c\(.*?\)|integer\(0\))}', r'{"\1"}', .) |>
> \(.) read.csv(text = .) |>
> mutate(across(2:3, \(col) lapply(col, \(x)
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
“The shorthand form \(x) x + 1 is parsed as function(x) x + 1. It may be helpful in making
code containing simple function expressions more readable.”
Color me unimpressed.
Over the decades I've seen several "who can write the shortest code" threads: in Fortran,
in C, in Splus, ... The same o
My vote is for the consistency of function calls always having parentheses,
including in pipes. Making them optional only saves two keystrokes, but
will add yet another inconsistency to confuse or trip folks up.
As for the new anonymous function syntax, I would prefer something more
human friendl
> 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().
Thanks for expressing this eloquently. I heartily agree.
On Mon, Dec 7, 2020 at 12:04 PM Therneau, Terry M., Ph.D. via R-devel <
r-devel@r-project.org> wrote:
> “The shorthand form \(x) x + 1 is parsed as function(x) x + 1. It may be
> helpful in making
> code containing simple function expressio
I don't disagree in principle, but the reality is users want shortcuts
and as a result various packages, in particular tidyverse, have been
providing them. Mostly based on formulas, mostly with significant
issues since formulas weren't designed for this, and mostly
incompatible (tidyverse ones are
On 07/12/2020 12:03 p.m., Gregory Warnes wrote:
My vote is for the consistency of function calls always having parentheses,
including in pipes. Making them optional only saves two keystrokes, but
will add yet another inconsistency to confuse or trip folks up.
As for the new anonymous function s
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 Mon, 7 Dec 2020, 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 happen a
It is easier to understand a function if you can see the entire
function body at once on a page or screen and excessive verbosity
interferes with that.
On Mon, Dec 7, 2020 at 12:04 PM Therneau, Terry M., Ph.D. via R-devel
wrote:
>
> “The shorthand form \(x) x + 1 is parsed as function(x) x + 1. I
Luke,
Mostly an aside. I think that pipes are a good addition, and it is clear
that you and
other R-core thought through many of the details. Congratulations on what
appears to be
solid work. I've used Unix since '79, so it is almost guarranteed that I like
the basic
idiom, and I expect
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
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
It has been very enlightening watching the discussion not only about the
existing and proposed variations of a data "pipe" operator in R but also
cognates in many other languages.
So I am throwing out a QUESTION that just asks if the pipeline as done is
pretty much what could also be done without
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
One advantage of the new pipe operator over magrittr's is that the former
works with substitute().
> f <- function(x, xlab=deparse1(substitute(x))) paste(sep="", xlab, ": ",
paste(collapse=", ",x))
> 2^(1:4) |> f()
[1] "2^(1:4): 2, 4, 8, 16"
> 2^(1:4) %>% f()
[1] ".: 2, 4, 8, 16"
This is because
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 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 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
I mostly agree with your comments on anonymous functions.
However, I think the main problem is cryptic-ness, rather than succinct-ness.
The backslash is a relatively universal symbol within programming
languages with C-like (ALGOL-like?) syntax.
Where it denotes escape sequences within strings.
U
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
Sorry, I should replace "cryptic-ness" from my last post, with
"unnecessary cryptic-ness".
Sometimes short symbolic expressions are necessary.
P.S.
Often, I wish I could write: f (x) = x^2.
But that's replacement function syntax.
On Tue, Dec 8, 2020 at 11:56 AM Abby Spurdle wrote:
>
> I mostly
I will stick my oar in here as a user to say that I find the \(x) syntax a bit
line-noise-ish.
David
> On 8 Dec 2020, at 00:05, Abby Spurdle wrote:
>
> Sorry, I should replace "cryptic-ness" from my last post, with
> "unnecessary cryptic-ness".
> Sometimes short symbolic expressions are nece
33 matches
Mail list logo
