Re: [Rd] [External] Re: should base R have a piping operator ?

Just for the record, and not that using return() calls like this is necessarily a good idea, it is possible to make a nested-call-based pipe that handles return() calls the way you want using delayedAssign. I've added it to the end of the file on gitlab. Time to move on to the stuff I've been avoi

Re: [Rd] [External] Re: should base R have a piping operator ?

Yes you can make my little example work by implementing dynamic scope with a stack for saving/restoring binding values. Given R's reflection capabilities and rm() with an envir argument that has its own issues. If you want to try to get this right and maintain it in your own packages that is up to

Re: [Rd] [External] Re: should base R have a piping operator ?

On 7 Oct 2019, at 18:17, Tierney, Luke wrote: > Here is a stylized example: The previous value of the binding should only be restored if it existed: g <- function(x, y) { rlang::scoped_bindings(xx = x, .env = parent.frame()) y get("xx") + 10 } # Good g(1, 2) #> [1] 11 # Still good? g(1,

Re: [Rd] [External] Re: should base R have a piping operator ?

Hi Kevin, > On 7 Oct 2019, at 18:42, Kevin Ushey wrote: > > My understanding is that the '.' placeholder is used so that the magrittr > pipe can be adapted to functions that aren't endomorphic or otherwise easily > pipeable. I would argue that: > > 1. Users could just create their own pipable

Re: [Rd] [External] Re: should base R have a piping operator ?

IMHO, if base R were to include a pipe operator, I think it should be much simpler than the magrittr pipe. It should satisfy the property that: x |> f(...) is equivalent to f(x, ...) Except, perhaps, in terms of when the promise for 'x' gets forced. We shouldn't need to mess with bindings

Re: [Rd] [External] Re: should base R have a piping operator ?

On Mon, 7 Oct 2019, Lionel Henry wrote: > > >> On 7 Oct 2019, at 17:04, Tierney, Luke wrote: >> >> Think about what happens if an >> argument in a pipe stage contains a pipe. (Not completely >> unreasonable, e.g. for a left_join). > > It should work exactly as it does in a local environment. > >

Re: [Rd] [External] Re: should base R have a piping operator ?

> On 7 Oct 2019, at 17:04, Tierney, Luke wrote: > > Think about what happens if an > argument in a pipe stage contains a pipe. (Not completely > unreasonable, e.g. for a left_join). It should work exactly as it does in a local environment. ``` `%foo%` <- function(x, y) { env <- parent.fra

Re: [Rd] [External] Re: should base R have a piping operator ?

On Mon, 7 Oct 2019, Lionel Henry wrote: > Hi Gabe, > >> There is another way the pipe could go into base R that could not be >> done in package space and has the potential to mitigate some pretty >> serious downsides to the pipes relating to debugging > > I assume you're thinking about the large s

Re: [Rd] should base R have a piping operator ?

> On 7 Oct 2019, at 15:36, Duncan Murdoch wrote: > > I think that could be done after parsing at run-time, as described in my > earlier message. Good point. > P.S. Were you just using |> to save typing, or is there a proposal to add a > new operator to the language? That would need pars

Re: [Rd] should base R have a piping operator ?

On 07/10/2019 8:38 a.m., Lionel Henry wrote: On 7 Oct 2019, at 13:47, Duncan Murdoch > wrote: On 07/10/2019 4:22 a.m., Lionel Henry wrote: Hi Gabe, There is another way the pipe could go into base R that could not be done in package space and has the potentia

Re: [Rd] error in [.terms

As a footnote, the update.formula function shares one of the flaws I mentioned in the earlier post > test <-  y ~ x1 + (x2=='abc') + x3 > update(test, . ~ .-x3) y ~ x1 + x2 == "abc" The original formula is valid but the updated one is not. Terry T. [[alternative HTML version delete

Re: [Rd] should base R have a piping operator ?

> > On 7 Oct 2019, at 13:47, Duncan Murdoch wrote: > > On 07/10/2019 4:22 a.m., Lionel Henry wrote: >> Hi Gabe, >>> There is another way the pipe could go into base R that could not be >>> done in package space and has the potential to mitigate some pretty >>> serious downsides to the pipes rela

Re: [Rd] should base R have a piping operator ?

On 07/10/2019 4:22 a.m., Lionel Henry wrote: Hi Gabe, There is another way the pipe could go into base R that could not be done in package space and has the potential to mitigate some pretty serious downsides to the pipes relating to debugging I assume you're thinking about the large stack tr

Re: [Rd] should base R have a piping operator ?

Hi Gabe, > There is another way the pipe could go into base R that could not be > done in package space and has the potential to mitigate some pretty > serious downsides to the pipes relating to debugging I assume you're thinking about the large stack trace of the magrittr pipe? You don't need a

[Rd] Changing HTML Error code message

Hello, I'm relatively new to using R and shiny. Currently, I'm getting the Error: Conflict (HTTP 409) when trying to access an html file from dropbox and this is fine, I know the reason. What I do have a problem with is trying to find a way to change Error code message. Instead of simply "Error: