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 avoiding ... Best, luke On Mon, 7 Oct 2019, Tierney, Luke wrote: > On Mon, 7 Oct 2019, Lionel Henry wrote: > >> >> >>> On 7 Oct 2019, at 17:04, Tierney, Luke <luke-tier...@uiowa.edu> 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.frame() >> >> # Use `:=` to avoid partial matching on .env/.frame >> rlang::scoped_bindings(. := x, .env = env) >> >> eval(substitute(y), env) >> } >> >> "A" %foo% { >> print(.) >> "B" %foo% print(.) >> print(.) >> } >> #> [1] "A" >> #> [1] "B" >> #> [1] "A" >> >> print(.) >> #> Error in print(.) : object '.' not found >> >> ``` >> >> The advantage is that side effects (such as assigning variables or calling >> `return()`) will occur in the expected environment. > > You get the assignment behavior with the nested call approach. (Not > that doing this is necessarily a good idea). > >> I don't see it causing >> problems except in artificial cases. Am I missing something? > > Here is a stylized example: > > f <- function(x, y) { > assign("xx", x, parent.frame()) > on.exit(rm(xx, envir = parent.frame())) > y > get("xx") + 1 > } > > ## This is fine: >> f(1, 2) > [1] 2 > > ## This is not: >> f(1, f(1, 2)) > Error in get("xx") : object 'xx' not found > > If you play these games whether you get the result you want, or an > obvious error, or just the wrong answer depends on argument evaluation > order and the like. You really don't want to go there. Not to mention > that you would be telling users they are not allowed to use '.' as a > variable name for their own purposes or you would be polluting their > environment with some other artificial symbol that they would see in > debugging. Just don't. > > Anything going in base needs to worry even about artificial cases. > Yes, there are things in base that don't meet that standard. No, that > is not a reason to add more. > >> I agree that restraining the pipe to a single placeholder (to avoid >> double evaluation) would be a good design too. >> >> I can't access https://gitlab.com/luke-tierney/pipes, it appears to be 404. > > Should be able to get there now. Needed to change the visibility --- > still learning my way around gitlab. > > Best, > > luke > >> Best, >> Lionel >> >> > > -- Luke Tierney Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics and Fax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: luke-tier...@uiowa.edu Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel