Project Lambda: Java Language Specification draft

[Neal Gafter]

On Fri, Jan 22, 2010 at 2:55 PM, Alex Buckley <Alex.Buckley at sun.com> wrote:
> It is a goal of this document
> to allow the implementer freedom as to how and when lambda expressions
> are evaluated.

On Tue, Jan 26, 2010 at 11:44 PM, Zdenek Tronicek <tronicek at fit.cvut.cz> wrote:
> Freedom is fine (and you can trust me, I spent a childhood in communist
> Czechoslovakia). However, one must ask here: what is the proposed freedom
> motivated by? And will not it blur the semantics?

It is motivated by a desire to allow a compiler to, for example,
statically allocate a lambda that captures no state.  For example, the
lambda expression

#()(3)

can be statically allocated by the generated code, even if it appears
in an inner loop.  That relieves the programmer from having to invent
a variable to store the lambda and move it out of the loop himself.

If the SAM is an interface, the only way the programmer could notice
this is by observing that the identity of the function object is the
same each time.  But yes, adding SAM classes to the mix blurs the
semantics further, which is one reason I oppose them.

Cheers,
Neal