Sorry, John. If I understand you correctly, R has no "Global Variables" in the sense that you seem to indicate. It does have a "Global environment", but variables referred to in a function but not found in the function environment are *not* necessarily searched for in the "Global Environment" -- they are searched for in the function's enclosing (defining) environment, then in that environment's enclosing environment if not found there, etc.
Consider: f <- f <- function(){ x <- 3 g <- function() x ## x not bound to a value in g's environment g ## f returns the function g } > environment() <environment: R_GlobalEnv> x <- 5 ## defined in the Global environment g <- f() ## Now what do you think g() returns? If I have misconstrued what you said, my apologies. Even if I have not, none of the above is revelatory -- it's all standard, documented R behavior. Cheers, Bert Cheers, Bert while something like d$something <- ... may seem like you're directly modifying the data it does not actually do so. Most R objects try to be immutable, that is, the object may not change after creation. This guarantees that if you have a binding for same object the object won't change sneakily. There is a data structure that is in fact mutable which are environments. For example compare L <- list() local({L$a <- 3}) L$a with E <- new.env() local({E$a <- 3}) E$ Valentin Petzel valen...@petzel.at via r-project.org 2:25 AM (5 hours ago) to avi.e.gross, R-help On Sun, Jan 15, 2023 at 5:07 PM Sorkin, John <jsor...@som.umaryland.edu> wrote: > > Richard, > I sent my prior email too quickly: > > A slight addition to your code shows an important aspect of R, local vs. > global variables: > > x <- 137 > f <- function () { > a <- x > x <- 42 > b <- x > list(a=a, b=b) > } > f() > print(x) > > When run the program produces the following: > > > x <- 137 > > f <- function () { > + a <- x > + x <- 42 > + b <- x > + list(a=a, b=b) > + } > > f() > $a > [1] 137 > > $b > [1] 42 > > > print(x) > [1] 137 > > The fist x, a <- x, invokes an x variable that is GLOBAL. It is known both > inside and outside the function. > The second x, x <- 42, defines an x that is LOCAL to the function, it is not > known to the program that called the function. The LOCAL value of x is used > in the expression b <- x. As can be seen by the print(x) statement, the > LOCAL value of x is NOT known by the program that calls the function. The > class of a variable, scoping (i.e. local vs. variable) can be a source of > subtle programming errors. A general recommendation is to AVOID use of a > global variable in a function, i.e. don't use a variable in function that is > not passed as a parameter to the function (as was done in the function above > in the statment a <- x). If you need to use a variable in a function that is > known by the program that calls the function, pass the variable as a argument > to the function e.g. > > Use this code: > > # Set values needed by function > y <- 2 > b <- 30 > > myfunction <- function(a,b){ > cat("a=",a,"b=",b,"\n") > y <- a > y2 <- y+b > cat("y=",y,"y2=",y2,"\n") > } > # Call the function and pass all needed values to the function > myfunction(y,b) > > Don't use the following code that depends on a global value that is known to > the function, but not passed as a parameter to the function: > > y <- 2 > myNGfunction <- function(a){ > cat("a=",a,"b=",b,"\n") > y <- a > y2 <- y+b > cat("y=",y,"y2=",y2,"\n") > } > # b is a global variable and will be know to the function, > # but should be passed as a parameter as in example above. > b <- 100 > myNGfunction(y) > > John > > ________________________________________ > From: R-help <r-help-boun...@r-project.org> on behalf of Sorkin, John > <jsor...@som.umaryland.edu> > Sent: Sunday, January 15, 2023 7:40 PM > To: Richard O'Keefe; Valentin Petzel > Cc: R help Mailing list > Subject: Re: [R] return value of {....} > > Richard, > A slight addition to your code shows an important aspect of R, local vs. > global variables: > > x <- 137 > f <- function () { > a <- x > x <- 42 > b <- x > list(a=a, b=b) > } > f() > print(x) > > ________________________________________ > From: R-help <r-help-boun...@r-project.org> on behalf of Richard O'Keefe > <rao...@gmail.com> > Sent: Sunday, January 15, 2023 6:39 PM > To: Valentin Petzel > Cc: R help Mailing list > Subject: Re: [R] return value of {....} > > I wonder if the real confusino is not R's scope rules? > (begin .) is not Lisp, it's Scheme (a major Lisp dialect), > and in Scheme, (begin (define x ...) (define y ...) ...) > declares variables x and y that are local to the (begin ...) > form, just like Algol 68. That's weirdness 1. Javascript > had a similar weirdness, when the ECMAscript process eventually > addressed. But the real weirdness in R is not just that the > existence of variables is indifferent to the presence of curly > braces, it's that it's *dynamic*. In > f <- function (...) { > ... use x ... > x <- ... > ... use x ... > } > the two occurrences of "use x" refer to DIFFERENT variables. > The first occurrence refers to the x that exists outside the > function. It has to: the local variable does not exist yet. > The assignment *creates* the variable, so the second > occurrence of "use x" refers to the inner variable. > Here's an actual example. > > x <- 137 > > f <- function () { > + a <- x > + x <- 42 > + b <- x > + list(a=a, b=b) > + } > > f() > $a > [1] 137 > $b > [1] 42 > > Many years ago I set out to write a compiler for R, and this was > the issue that finally sank my attempt. It's not whether the > occurrence of "use x" is *lexically* before the creation of x. > It's when the assignment is *executed* that makes the difference. > Different paths of execution through a function may result in it > arriving at its return point with different sets of local variables. > R is the only language I routinely use that does this. > > So rule 1: whether an identifier in an R function refers to an > outer variable or a local variable depends on whether an assignment > creating that local variable has been executed yet. > And rule 2: the scope of a local variable is the whole function. > > If the following transcript not only makes sense to you, but is > exactly what you expect, congratulations, you understand local > variables in R. > > > x <- 0 > > g <- function () { > + n <- 10 > + r <- numeric(n) > + for (i in 1:n) { > + if (i == 6) x <- 100 > + r[i] <- x + i > + } > + r > + } > > g() > [1] 1 2 3 4 5 106 107 108 109 110 > > > On Fri, 13 Jan 2023 at 23:28, Valentin Petzel <valen...@petzel.at> wrote: > > > Hello Akshay, > > > > R is quite inspired by LISP, where this is a common thing. It is not in > > fact that {...} returned something, rather any expression evalulates to > > some value, and for a compound statement that is the last evaluated > > expression. > > > > {...} might be seen as similar to LISPs (begin ...). > > > > Now this is a very different thing compared to {...} in something like C, > > even if it looks or behaves similarly. But in R {...} is in fact an > > expression and thus has evaluate to some value. This also comes with some > > nice benefits. > > > > You do not need to use {...} for anything that is a single statement. But > > you can in each possible place use {...} to turn multiple statements into > > one. > > > > Now think about a statement like this > > > > f <- function(n) { > > x <- runif(n) > > x**2 > > } > > > > Then we can do > > > > y <- f(10) > > > > Now, you suggested way would look like this: > > > > f <- function(n) { > > x <- runif(n) > > y <- x**2 > > } > > > > And we'd need to do something like: > > > > f(10) > > y <- somehow_get_last_env_of_f$y > > > > So having a compound statement evaluate to a value clearly has a benefit. > > > > Best Regards, > > Valentin > > > > 09.01.2023 18:05:58 akshay kulkarni <akshay...@hotmail.com>: > > > > > Dear Valentin, > > > But why should {....} "return" a value? It > > could just as well evaluate all the expressions and store the resulting > > objects in whatever environment the interpreter chooses, and then it would > > be left to the user to manipulate any object he chooses. Don't you think > > returning the last, or any value, is redundant? We are living in the > > 21st century world, and the R-core team might,I suppose, have a definite > > reason for"returning" the last value. Any comments? > > > > > > Thanking you, > > > Yours sincerely, > > > AKSHAY M KULKARNI > > > > > > ---------------------------------------- > > > *From:* Valentin Petzel <valen...@petzel.at> > > > *Sent:* Monday, January 9, 2023 9:18 PM > > > *To:* akshay kulkarni <akshay...@hotmail.com> > > > *Cc:* R help Mailing list <r-help@r-project.org> > > > *Subject:* Re: [R] return value of {....} > > > > > > Hello Akshai, > > > > > > I think you are confusing {...} with local({...}). This one will > > evaluate the expression in a separate environment, returning the last > > expression. > > > > > > {...} simply evaluates multiple expressions as one and returns the > > result of the last line, but it still evaluates each expression. > > > > > > Assignment returns the assigned value, so we can chain assignments like > > this > > > > > > a <- 1 + (b <- 2) > > > > > > conveniently. > > > > > > So when is {...} useful? Well, anyplace where you want to execute > > complex stuff in a function argument. E.g. you might do: > > > > > > data %>% group_by(x) %>% summarise(y = {if(x[1] > 10) sum(y) else > > mean(y)}) > > > > > > Regards, > > > Valentin Petzel > > > > > > 09.01.2023 15:47:53 akshay kulkarni <akshay...@hotmail.com>: > > > > > >> Dear members, > > >> I have the following code: > > >> > > >>> TB <- {x <- 3;y <- 5} > > >>> TB > > >> [1] 5 > > >> > > >> It is consistent with the documentation: For {, the result of the last > > expression evaluated. This has the visibility of the last evaluation. > > >> > > >> But both x AND y are created, but the "return value" is y. How can this > > be advantageous for solving practical problems? Specifically, consider the > > following code: > > >> > > >> F <- function(X) { expr; expr2; { expr5; expr7}; expr8;expr10} > > >> > > >> Both expr5 and expr7 are created, and are accessible by the code > > outside of the nested braces right? But the "return value" of the nested > > braces is expr7. So doesn't this mean that only expr7 should be accessible? > > Please help me entangle this (of course the return value of F is expr10, > > and all the other objects created by the preceding expressions are deleted. > > But expr5 is not, after the control passes outside of the nested braces!) > > >> > > >> Thanking you, > > >> Yours sincerely, > > >> AKSHAY M KULKARNI > > >> > > >> [[alternative HTML version deleted]] > > >> > > >> ______________________________________________ > > >> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see > > >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-help&data=05%7C01%7CJSorkin%40som.umaryland.edu%7C75c2bc42c20b4c03601d08daf75a4405%7C717009a620de461a88940312a395cac9%7C0%7C0%7C638094264319036570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Jp7JGV%2BVKkAx3SI%2Fak%2BiEIkUraGyQBTfSLWqRRUYmaQ%3D&reserved=0 > > >> PLEASE do read the posting guide > > https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.r-project.org%2Fposting-guide.html&data=05%7C01%7CJSorkin%40som.umaryland.edu%7C75c2bc42c20b4c03601d08daf75a4405%7C717009a620de461a88940312a395cac9%7C0%7C0%7C638094264319036570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Got4ab%2BEO6LD%2FOXqp9j9ImnSn0zi8vhV6YZMD7OJ8WU%3D&reserved=0 > > >> and provide commented, minimal, self-contained, reproducible code. > > > > [[alternative HTML version deleted]] > > > > ______________________________________________ > > R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-help&data=05%7C01%7CJSorkin%40som.umaryland.edu%7C75c2bc42c20b4c03601d08daf75a4405%7C717009a620de461a88940312a395cac9%7C0%7C0%7C638094264319036570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Jp7JGV%2BVKkAx3SI%2Fak%2BiEIkUraGyQBTfSLWqRRUYmaQ%3D&reserved=0 > > PLEASE do read the posting guide > > https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.r-project.org%2Fposting-guide.html&data=05%7C01%7CJSorkin%40som.umaryland.edu%7C75c2bc42c20b4c03601d08daf75a4405%7C717009a620de461a88940312a395cac9%7C0%7C0%7C638094264319036570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Got4ab%2BEO6LD%2FOXqp9j9ImnSn0zi8vhV6YZMD7OJ8WU%3D&reserved=0 > > and provide commented, minimal, self-contained, reproducible code. > > > > [[alternative HTML version deleted]] > > ______________________________________________ > R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-help&data=05%7C01%7CJSorkin%40som.umaryland.edu%7C75c2bc42c20b4c03601d08daf75a4405%7C717009a620de461a88940312a395cac9%7C0%7C0%7C638094264319036570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Jp7JGV%2BVKkAx3SI%2Fak%2BiEIkUraGyQBTfSLWqRRUYmaQ%3D&reserved=0 > PLEASE do read the posting guide > https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.r-project.org%2Fposting-guide.html&data=05%7C01%7CJSorkin%40som.umaryland.edu%7C75c2bc42c20b4c03601d08daf75a4405%7C717009a620de461a88940312a395cac9%7C0%7C0%7C638094264319036570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Got4ab%2BEO6LD%2FOXqp9j9ImnSn0zi8vhV6YZMD7OJ8WU%3D&reserved=0 > and provide commented, minimal, self-contained, reproducible code. > > ______________________________________________ > R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-help&data=05%7C01%7CJSorkin%40som.umaryland.edu%7C75c2bc42c20b4c03601d08daf75a4405%7C717009a620de461a88940312a395cac9%7C0%7C0%7C638094264319036570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Jp7JGV%2BVKkAx3SI%2Fak%2BiEIkUraGyQBTfSLWqRRUYmaQ%3D&reserved=0 > PLEASE do read the posting guide > https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.r-project.org%2Fposting-guide.html&data=05%7C01%7CJSorkin%40som.umaryland.edu%7C75c2bc42c20b4c03601d08daf75a4405%7C717009a620de461a88940312a395cac9%7C0%7C0%7C638094264319036570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Got4ab%2BEO6LD%2FOXqp9j9ImnSn0zi8vhV6YZMD7OJ8WU%3D&reserved=0 > and provide commented, minimal, self-contained, reproducible code. > > ______________________________________________ > R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide http://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. ______________________________________________ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.