Updated State of the Lambda

[Reinier Zwitserloot]

Entirely separate from the discussion around implementation details, having
"this" refer to the outer class is something that makes far more sense (and
has been claimed, repeatedly, as the preferred option for _any_ lambdas,
going all the way back to the inception of this mailing list). I'm sure
opinions are divided on the issue, but from my (possibly biased, as I prefer
this new state) experience, there are more that like outer this vs. inner
this. Popular opinion doesn't have to be right, of course. Still, combine it
with the implementation reasons for going with outer this, and the burden of
proof would appear to be on the inner this camp.

I myself have been asking for 'this = refers to outer' by default because it
makes more sense when writing lambdas: They don't look like classes anymore,
and, I rate the number of times I need Outer.this at about 15 to 50 times
more often than I need Inner.this. I'm expecting the vast majority of SAM
types to be interfaces, and in such a scenario there is absolutely no reason
for an inner this reference except for recursion and recursion-like
practices. I'm speaking specifically of using "this" as an object reference,
and not the "this.x" syntax to clarify which field / method you're referring
to. Those are scoped in reverse (If the SAM type has a field named "foo" and
the outer also does, then an unqualified "foo" reference will refer to the
SAM type's). Therefore, using Outer.this syntax will not be necessary; its
only for clarification: "x" refers to lambda's x, and "this.x" refers to
outer's X. You'd only need it when writing a lambda that is itself in an
inner class.

I don't agree this latest state is inconsistent: This latest state simply
does not attempt to paint a lambda as syntax sugar for anonymous inner class
literals. The previous state also didn't, but that one WAS inconsistent
because 'this' referred to the inner instance. Whether "return" or "yield"
is used is immaterial, other than the idea that using "yield" makes the case
that lambdas aren't syntax sugar for AICs even stronger. It wasn't the only
reason lambdas aren't AICs, though (Re: Alex Blewitt).

NB: I'd like to echo Stephen Colebourne's request for a timeboxed syntax
discussion window, to be held when all issues of structure and
implementation have been sorted out.



 --Reinier Zwitserloot



On Mon, Oct 18, 2010 at 5:29 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> More the latter.  Some of the ancillary benefits include: removing identity
> opens up opportunities for VM optimization; nailing down the type of 'this'
> greatly simplifies type inference.  And lambdas that need to refer to
> themselves are, in practice, a corner case.  It is a shame that we created
> an inconsistency (lambdas behave differently from inner classes) but in the
> end we felt the new semantics were so far preferable that it was worth doing
> something different.
>
> On Oct 18, 2010, at 1:04 AM, Peter Levart wrote:
>
> > This is good news. In particular the 1st notable change below. This is a
> move in the right direction. I wonder if the reason for the cahnge was a
> result of desire to keep the door open for possible future extension to
> support "transparent" lambda or just of realization that lexical scoping has
> a better solution:problem ratio than annonymous inner classes style of
> scoping? In either case I think we are getting better lambda this way.
> > I can also understand that the benefit of "yield" was not worth the
> additional confusion it might cause, although replacing it for "return" it
> is a step away from transparent lambda.
> >
> > Regards, Peter
> >
> >
> > On 10/15/10, Brian Goetz wrote:
> >> An updated draft (Version 3) of the State of the Lambda has been
> published at:
> >>
> >>   http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-3.html
> >>
> >> Notable differences from the previous draft include:
> >>  - 'this' in lambda expressions is lexically scoped
> >>  - 'yield' keyword dropped in favor of 'return'
> >>  - new syntax
> >>
> >> Maurizio will be pushing an implementation conforming to this draft
> soon.
> >>
> >>
> >>
>
>
>