question on lambda expressions and conflicting scope of variables

[Anil Philip]

@Venkat Subramaniam
Can you please look at this post I made in the certification forum?
https://coderanch.com/t/775369/certification/Sybex-Ch-Lambdas-difference-compiler

per Jeanne's comment,

In location B, the lambda isn't in scope anymore so "c" doesn't produce such a conflict.

I still do not understand why the variables are in scope in 'LOCATION A', but out of scope in 'LOCATION B'.
To me, a lambda expression is something inserted that exists beyond the life of that code block.
It will be executed sometime later on, outside the life of the block.
It is like an alien visiting earth
So, both locations A and B have to be taken into account.

[Mikalai Zaikin]

1) Lambda expression can use a local variable (if it is final or effectively final) -- it's called a lambda closure

2) The code you're talking about follows Java variable scope rule:

CASE 1:

void myMethod() {
  var a = 0;
  {
     // cannot declare here variable 'a', as existing yet in scope
  }
}

CASE 2:

void myMethod() {
  {
       var a = 0; // fine
  }
  var a = 0; // fine, the above 'a' scope ended, no conflict
}

[Burk Hufnagel]

Anil Philip wrote:@Venkat Subramaniam
Can you please look at this post I made in the certification forum?
https://coderanch.com/t/775369/certification/Sybex-Ch-Lambdas-difference-compiler

per Jeanne's comment,

In location B, the lambda isn't in scope anymore so "c" doesn't produce such a conflict.

I still do not understand why the variables are in scope in 'LOCATION A', but out of scope in 'LOCATION B'.
To me, a lambda expression is something inserted that exists beyond the life of that code block.
It will be executed sometime later on, outside the life of the block.
It is like an alien visiting earth
So, both locations A and B have to be taken into account.

I think this answers your question.
Here's the code you're asking about:

public void remove(List˂Character˃ chars) {
    char end = 'z';
    // LOCATION A
    Predicate˂Character˃ predicate = c -˃ {
        char start = 'a'; return start ˂= c && c ˂= end; 
    };
    // LOCATION B
}

And here's the code to be inserted:

char start = 'a';
char c = 'x';
chars = null;

If you insert the code at location A then variables "start" and "c" are already declared which causes problems when they're re-declared in the lambda. However, at location B, the variables declared inside the lambda are "out of scope" because they're declared inside the lambda and the closing curly bracket for the lambda occurs before we get to location B.

Hoping this helps,
Burk

[Anil Philip]

Thank you for the code example. It made things clearer.

Mikalai Zaikin wrote:1) Lambda expression can use a local variable (if it is final or effectively final) -- it's called a lambda closure

2) The code you're talking about follows Java variable scope rule:

CASE 1:

void myMethod() {
  var a = 0;
  {
     // cannot declare here variable 'a', as existing yet in scope
  }
}

CASE 2:

void myMethod() {
  {
       var a = 0; // fine
  }
  var a = 0; // fine, the above 'a' scope ended, no conflict
}

[Anil Philip]

Shouldn't Lambdas use scope more like Local Classes rather than block scope or what you refer to: "Java variable scope rule"?
(Wouldn't scope rules for local classes be more appropriate).

Mikalai Zaikin wrote:1) Lambda expression can use a local variable (if it is final or effectively final) -- it's called a lambda closure

2) The code you're talking about follows Java variable scope rule:

[Stephan van Hulst]

No.

Lambdas are often used to close over a variable that has been declared outside the lambda expression. If you were able to shadow the outer variable with a lambda parameter, that could lead to a lot of confusion for people reading your code.

The same is probably true for local classes, but I can think of two reasons why this restriction doesn't apply to them:

The compiler reuses most of the code for parsing normal classes to parse local classes, and normal classes don't have such a restriction.

Local classes were added to the language waaay back in Java 1.1, and the designers may not have had the foresight to add the restriction.

With lambda expressions, the designers had a new opportunity to add this restriction to them.