Project Lambda: Java Language Specification draft 0.1.5

[Alex Buckley]

Neal,

Thanks for your comments. I agree with most and have either resolved 
them, or clarified why they don't apply, in the draft spec. Some points 
remain:

Neal Gafter wrote:
> - It is unclear what the type of "this" is in an expression lambda. Is
> it forbidden?
> 
> - I wonder if the identity of a lambda can change spuriously.  For
> example, if "this" refers to the lambda expression, can it be expected
> to have the same value on each invocation of the same lambda
> expression?  In other words,
> 
> #Object() self = #()this;
> assert self.() == self.(); // guaranteed??
> 
> - Similar question if the lambda has been converted to a SAM
> 
> Object() self1 = #()this;
> Callable<Object> self2 = self1;
> assert self1.() == self2.call(); // guaranteed??

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.

> - 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?

> - 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.

Alex