Implementing recursive lambda with MethodHandle

[Peter Levart]

On Tuesday 23 February 2010 14:49:45 Alex Blewitt wrote:
> 
> On 23 Feb 2010, at 12:27, Peter Levart wrote:
> 
> >> But if we've blown transparency with the lack of (non-final) variable capture, returns/continue/break acting differently from within a lambda than outside,
> > 
> > These are all restrictions that make such code illegal (doesn't compile) and not, as you claim, "acting differently"...
> 
> That's not strictly true. You can still use break/continue/returns inside the lambda; but they have potentially different meaning htan before. (Jumping to a label outside may be a compile error; but return-from-lambda will be compilable and be different than return-from-enclosing-emthod.)

Yeah, the unfortunate return.

> 
> >> there doesn't appear to be any argument against having 'this' as meaning something different inside a scope as well, other than personal expectations.
> > 
> > Now this is something that will compile, one way or another. It's just semantics of "this" that are questioned.
> 
> Like the semantics of 'return' being questioned as well? 

Unfortunately there is no elegant way to perform transparent early returns from lambdas other than inventing new keyword (which is still not transparent when nesting) or some awkward lambda-labeling mechanism with awkward labeled value returning construct (for example: return label : value;).
There was a moment of "hope" when Alex Buckley considered dropping statement lambdas. Expression lambdas combined with block expressions (see CfJ 0.6b http://www.javac.info/closures-v06b.html) would be a way to go. Early returns from such block expressions could be performed by combining two existing Java features: Deffinite Assignment rules + labeled statement/labeled break.

But as 0.1.5 spec stands currently, statement lambdas are still there with this/return emulating this/return in annon inner classes and block expression is not part of the spec.

> 
> >> Lastly, we still can't use 'this' transparently in the 0.1.5 spec, since 'this' is explicitly disallowed at the current time.
> > 
> > Only in expression lambdas or return statements of statement lambdas, If I remember correctly.
> 
> This still means there are code segments which cannot be converted into an (expression) lambda, so the transparency argument is already broken for those cases.

That's because "this" is refering to the lambda instance and therefore the compiler has trouble to infer lambda's return type. If it was refering to enclosing class instance then the restrictions to use "this" in expression lambdas and return statements of statement lambdas could be lifted.

> 
> Alex

Regards, Peter