State of the Lambda

[Nathan Bryant]

So,

#foo.setBar is sugar for { Bar bar -> foo.setBar(bar) }

An alternate desugared form, perhaps more convenient for the runtime:

{ Foo x -> { Bar bar -> x.setBar(bar) } } (foo) // Is this legal?

If the first desugaring is accurate, then "foo" must be effectively
final. If the second is accurate, then it seems foo need not be, but
would be copied
 
-----Original Message-----
From: lambda-dev-bounces at openjdk.java.net
[mailto:lambda-dev-bounces at openjdk.java.net] On Behalf Of Brian Goetz
Sent: Thursday, July 08, 2010 5:37 PM
To: John Rose
Cc: lambda-dev at openjdk.java.net
Subject: Re: State of the Lambda

>> I'm a little bit worried that method references with receiver
variables do
>> an copy. ... A possible solution is to require such receiver
>> variables to be (implicitly) final.
>
> This is one of those times where syntax might imply something deep
about an expression.  Brian's sketch uses a prefix "#" to introduce a
method lifted to a function (and perhaps partially applied to a
receiver).
>
> The prefix looks like it might govern the evaluation of the expression
to the right.  An infix operator would much more clearly express that
the left hand side of the expression (at least) is evaluated in the
normal left-to-right order of Java expressions.  (Some infix operators,
?:&&  || have special rules for evaluation order, but it only applies to
the right of the operator.)

My intention for method refs for non-static methods is that the receiver

reference is evaluated and copied (likely as part of the method handle 
binding); this is a binding of a method handle with a specific receiver,
not 
syntactic sugar for "whatever the receiver happens to be at the time the

lambda is invoked, call it."