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 <valentin at 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_e4 at 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 <valentin at petzel.at>
*Sent:* Monday, January 9, 2023 9:18 PM
*To:* akshay kulkarni <akshay_e4 at hotmail.com>
*Cc:* R help Mailing list <r-help at 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_e4 at 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]]

        [[alternative HTML version deleted]]