Re: [Rd] anonymous functions

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

Re: [Rd] anonymous functions

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

Re: [Rd] New pipe operator

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

Re: [Rd] anonymous functions

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.

Re: [Rd] New pipe operator

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

[Bioc-devel] Request access to EGSEA123

Hi there, I am one of the maintainers of EGSEA123 workflow package and it seems the package is failing due to an error that I needs to fix. Can you please give me access to the package. This is my BiocCredentials email m.hamdo...@gmail.com Thanks, Monther

Re: [Rd] New pipe operator

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

Re: [Rd] New pipe operator

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

[Bioc-devel] List of Deprecated Packages for Bioc3.13

The Bioconductor Team is continuing to identify packages that will be deprecated in the next release to allow for the Bioconductor community to respond accordingly. The list will be updated monthly. This is the current list of deprecated packages for Bioc 3.13 : User Requested Software:

Re: [Rd] [R/S-PLUS] [EXTERNAL] Re: [External] anonymous functions

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

Re: [Rd] New pipe operator

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

[Rd] sequential chained operator thoughts

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

Re: [Rd] New pipe operator

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

Re: [Rd] New pipe operator

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

Re: [Rd] [R/S-PLUS] [EXTERNAL] Re: [External] anonymous functions

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

Re: [Rd] anonymous functions

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.

Re: [Rd] [External] Re: New pipe operator

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

Re: [Rd] New pipe operator

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

Re: [Rd] [External] Re: New pipe operator

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

Re: [Rd] [External] anonymous functions

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

Re: [Rd] anonymous functions

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

Re: [Rd] New pipe operator

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

Re: [Rd] [External] Re: New pipe operator

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

[Rd] anonymous functions

“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

Re: [Rd] New pipe operator

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

Re: [Rd] [External] Re: New pipe operator

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)

Re: [Rd] New pipe operator

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

Re: [Bioc-devel] Illegal Version Bump after accidentally pushing Version Bump to 1.1.1

Hi Lori, Thank you very much! I will do this. Best, Lucy From: Kern, Lori Sent: Monday, December 7, 2020 3:34 PM To: Sinke, L.J. (MOLEPI) ; bioc-devel@r-project.org Subject: [MOGELIJK SPAM ! *] Re: Illegal Version Bump after accidentally pushing Version Bump to 1.1.1 I answered on the

Re: [Rd] New pipe operator

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

Re: [Rd] New pipe operator

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

Re: [Rd] New pipe operator

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`(...) >

Re: [Rd] [External] Re: New pipe operator

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

Re: [Bioc-devel] Illegal Version Bump after accidentally pushing Version Bump to 1.1.1

I answered on the support site too but please check out this documentation http://bioconductor.org/developers/how-to/git/bug-fix-in-release-and-devel/ You need to push to the RELEASE_3_12 branch not the master branch. the RELEASE_3_12 is the Bioconductor release 3.12 branch while the master

Re: [Bioc-devel] Illegal Version Bump after accidentally pushing Version Bump to 1.1.1

Hi, Which package are you talking about? Best, Nitesh > On Dec 7, 2020, at 4:32 AM, wrote: > > I was hoping to update my Bioconductor package, which I now know should have > been a version bump from 1.0.0 to 1.0.1. However, I have by mistake version > bumped to 1.1.1 meaning that the

[Bioc-devel] Illegal Version Bump after accidentally pushing Version Bump to 1.1.1

I was hoping to update my Bioconductor package, which I now know should have been a version bump from 1.0.0 to 1.0.1. However, I have by mistake version bumped to 1.1.1 meaning that the devel version is correct, but the release version is still on 1.0.0. When I try to correct this by editing

Re: [Rd] [External] Re: New pipe operator

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

Re: [Rd] New pipe operator

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

Re: [Rd] New pipe operator

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

Re: [Rd] New pipe operator

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