Transparancy

[Reinier Zwitserloot]

Given that I espoused the benefits of dropping function types altogether
state-of-lambda is like music to my ears, but still, a note on yield vs.
this. I too feel the combination makes rather little sense.

To preserve (future) transparency, yield is used instead of return. Okay. It
has a secondary benefit, even, in that folks looking at java code definitely
won't confuse an 'inner' return with an 'outer' one, as inner returns are
now called 'yield'. However, if future transparency is the goal, with the
further solution to treat return as definitely returning from a method, and
not from the nearest returnable thing in lexical scope, then why is 'this'
instead defined as a reference to the nearest object in lexical scope?

Consider too that unqualified references (x instead of this.x) already work
via lexical scoping. i.e. they would prefer the local SAM type's members
before the containing class. This means that there's virtually no need to
*EVER* use inner.this. I can't think of a single compelling use case for it.
Even the previous last hope of a use case for it, recursion, does not apply
here: If one wants to call oneself, you do have a name for this; all lambdas
are always fitted to a SAM type, and the one abstract method in a SAM type
has a name. That's self, and you can call it from inside a lambda literal
without messing up resolution. Thus:

Comparator<String> c = {a, b -> a.startsWith("foo") ? -1 :
compare(a.toLowerCase(), b)};

The above example uses recursion; the call to 'compare' is in fact a call to
self.

The only remaining use case is passing self as a reference to for example
another method from inside the lambda. This can be solved by allowing an
"X.this" syntax, where X takes the name of the SAM type. This wasn't really
feasible with function types but it works great when all lambda literals
must fit to a SAM type:

Comparator<String> c = {a, b -> compare(Comparator.this.toString(), a + b)};


This concept can only go wrong when trying to define a lambda literal that
will fit to SAM type FOO in code that is itself in an instance method of
FOO, but that seems like an extremely academic (read: so rare it can be
ignored as unsolved edge case) problem that can be ignored safely by
defining arbitrary but specified behaviour (such as: specified this
references use lexical scoping, i.e. it would refer to the closure).

--Reinier Zwitserloot



On Wed, Jul 7, 2010 at 10:12 PM, Neal Gafter <neal at gafter.com> wrote:

> On Wed, Jul 7, 2010 at 12:59 PM, Pavel Minaev <int19h at gmail.com> wrote:
>
> > On Wed, Jul 7, 2010 at 12:47 PM, Neal Gafter <neal at gafter.com> wrote:
> > > My experience is exactly the opposite.  In C# "this" is inherited from
> > the
> > > enclosing scope.  No members are inherited from the delegate object
> type
> > > into the body of the lambda expression.
> >
> > This doesn't mean that C# programmers don't think of lambdas as
> > methods. It means that they think of them as methods on the class, in
> > the body of which the lambda is written (rather than a delegate type)
> > - but a method nonetheless. Consequently, they expect "return" to work
> > in the body of the lambda in the same manner as in any other method.
> >
>
> Even if I accept this logic, this is quite different from what is proposed
> for project lambda.
>
>