similar to: R-alpha: Environment strangeness

A private reply by Martin made me realize that I was wrong about stopifnot(exprs=TRUE) . It actually works fine. I apologize. What I tried and was failed was stopifnot(exprs=T) . Error in exprs[[1]] : object of type 'symbol' is not subsettable The shortcut assert <- function(exprs) stopifnot(exprs = exprs) mentioned in "Warning" section of the documentation similarly fails

Another possible shortcut definition: assert <- function(exprs) do.call("stopifnot", list(exprs = substitute(exprs), local = parent.frame())) After thinking again, I propose to use ??? ? ? stop(simpleError(msg, call = if(p <- sys.parent()) sys.call(p))) - It seems that the call is the call of the frame where stopifnot(...) is evaluated. Because that is the correct context, I

Hi R-listers, I am trying to better undertand what we would call "functional paradigm" use of S/R to better map my programming activities in other languages. This little function is aimed to create an object (at the end end, it would have it's own class): -- myObject =function(){ list( a=1, foo=function(b) { cat("b:",b)

Dear R-devel, The most popular piping operator sits in the package `magrittr` and is used by a huge amount of users, and imported /reexported by more and more packages too. Many workflows don't even make much sense without pipes nowadays, so the examples in the doc will use pipes, as do the README, vignettes etc. I believe base R could have a piping operator so packages can use a pipe in

My points: - The 'withCallingHandlers' construct that is used in current 'stopifnot' code has no effect. Without it, the warning message is the same. The overridden warning is not raised. The original warning stays. - Overriding call in error and warning to 'cl.i' doesn't always give better outcome. The original call may be "narrower" than 'cl.i'. I

Hi R users! I was looking at some of the example code for the "environment" function. Here it is: e1 <- new.env(parent = baseenv()) # this one has enclosure package:base. e2 <- new.env(parent = e1) assign("a", 3, envir=e1) ls(e1) ls(e2) exists("a", envir=e2) # this succeeds by inheritance exists("a", envir=e2, inherits = FALSE)

my understanding of `eval' behaviour is obviously incomplete. my question: usually `eval(expr)' and `eval(expr, envir=parent.frame())' should be identical. why does the last `eval' (yielding `r3') in this code _not_ evaluate in the local environment of function `f' but rather in the global environment (if `f' is called from there)?

Here is a patch to function 'stopifnot' that adds 'evaluated' argument and makes 'exprs' argument in 'stopifnot' like 'exprs' argument in 'withAutoprint'. --- stop.R 2019-05-30 14:01:15.282197286 +0000 +++ stop_new.R 2019-05-30 14:01:51.372187466 +0000 @@ -31,7 +31,7 @@ .Internal(stop(call., .makeMessage(..., domain = domain))) }

I've noticed the following oddity where capture.output() prevents eval() from evaluating an expression in the specified environment. I'm not sure if it is an undocumented feature or a bug. It caused me many hours of troubleshooting. By posting it here, it might save someone else from doing the same exercise. Start by defining foo() which evaluates an expression locally in a given

Hello, Suppose I have an expression, E, which accesses some variables present in an environment V. I do this via eval(E,envir=V) however all assignments end up in V. I would like the results of assignments in E to end up in the .GlobalEnv ? Or at least the calling environment. Is there a quick way to this instead of iterating over all objects E and assigning into .GlobalEnv? Thank you Saptarshi

Hi John, Thanks, but the Bizzaro pipe comes with many flaws though : * It's not a single operator * It has a different precedence * It cannot be used in a subcall * The variable assigned to must be on the right * It doesn't trigger indentation when going to the line * It creates/overwrite a `.` variable in the worksace. And it doesn't deal gracefully with some lazy evaluation edge

Code like df <- data.frame(x=1:10) y <- 20:29 eval(quote(x+y), env=df) does what you might expect: it looks for x and y in the data.frame, and when it doesn't find y there, it looks in the parent environment. However, sometimes I'd like to construct a single environment out of df, so that I can pass it to nested functions and get the same behaviour. Right now, I get the wrong

Code like df <- data.frame(x=1:10) y <- 20:29 eval(quote(x+y), env=df) does what you might expect: it looks for x and y in the data.frame, and when it doesn't find y there, it looks in the parent environment. However, sometimes I'd like to construct a single environment out of df, so that I can pass it to nested functions and get the same behaviour. Right now, I get the wrong

This is a trivial example I set up to see if I could pass an environment and use the variables in it (this is for a function that will be called many times and might need to use a lot of variables that won't be changing, so it seemed more sensible to use an environment). Here's the code: ######################### #The outer function run.internal.env <- function(x) { in.env <-

Dear all, I am working on a function formula.design that should automatically generate reasonable lm formulae for a number of different designs. All works well as long as all variables used are columns of the design data frame. For one function, I would like to incorporate a dummy variable for center points that is not a column of the design. Without this function, it would work like this (at

Shouldn't the following 4 ways to alter an object in a locked environment either all work or all fail? (All working would be nice, I think.) E <- new.env() assign("var", c(1,2,3,4), envir=E) lockEnvironment(E, bindings=FALSE) E$var[1] <- 101 ; E$var #[1] 101 2 3 local(var[2] <- 102, envir=E) #Error in eval(expr, envir, enclos) : # cannot add

Dear mailing list, I have found some strange behaviour which I think relates to parent frames and eval. Can anyone explain what's going on here? First example: > test.parent.funcs_ function() { outer.var_ 5 subfunc1_ function() substitute( outer.var, envir=parent.frame()) print( subfunc1()) subfunc2b_ function() eval( quote( outer.var), envir=parent.frame()) print(

While poking around the C++ code in the dplyr package I ran across the idiom Rf_defineVar(symbol, R_UnboundValue, environment) to [sort of] remove 'symbol' from 'environment' Using it makes the R-level functions objects(), exists(), and get() somewhat inconsistent and I was wondering if that was intended. E.g., use SHLIB to make something from the following C code that

I would like to be able, inside a function, to create a new function, and use it as part of a formula as an argument to, say, gnls or nlme. for example: MyTop <- function(data=dta) { Cexp <- function(dose,A,B,m){...} Model <- as.formula(paste("y","~ Cexp(",paste(formals(Cexp),collapse =", "),")")) MyCall <-

I wish I had started with "I am disappointed that lm() doesn't continue its search for weights into the calling environment" or "the fact that lm() looks only in the formula environment and data frame for weights doesn't seem consistent with how other values are treated." But I did not. So I do apologize for both that and for negative tone on my part. Simplified