Project Lambda: Java Language Specification draft 0.1.5

[Neal Gafter]

On Thu, Feb 18, 2010 at 5:10 PM, Alex Buckley <Alex.Buckley at sun.com> wrote:
> If 'this' is banned in an expression lambda, and in returns of a
> statement lambda, then a lambda instance's identity cannot be exposed,
> and the question is moot.

As Josh pointed out, if "this" refers to the lambda anywhere inside
the lambda, then its identity is observable.

Another problem with having "this" refer to the lambda that we did not
discuss before is that it does not compose well.  Specifically, a
lambda written within another lambda has no way to refer to "this" of
the enclosing lambda.

>> - It isn't clear why you would want special rules for recursive
>> lambdas in this revision of the spec, given that one could just invoke
>> "this" inside the lambda.  Or, failing that, just use a method or an
>> anonymous inner class.
>
> To which special rules do you refer?

I'm referring to the discussion of possible rules, including the
phrase "Current options for self-reference include:"

>> - The spec "It is a compile-time error to modify the value of an
>> effectively-final variable in the body of a lambda expression." is
>> meaningless.  If there were an assignment to a variable from an
>> enclosing scope in a lambda, the variable would not be definitely
>> unassigned at that point, and so by definition the variable would not
>> be effectively-final.  So this rule could never be applied in the way
>> you appear to intend.
>
> True. How about: It is a compile-time error to modify the value of a
> variable that is effectively-final outside the body of a lambda
> expression, from inside the body of the lambda expression.

Again, unnecessary, because such a variable does not fit the
definition of effectively final.  Specifically, the variable is not
definitely unassigned at the point of its assignment (in the lambda),
and so it is not effectively final.  I think it is best just to delete
this rule as being redundant with other more precise rules.