A peek past lambda

[Brian Goetz]

Along the lines that we've been discussing today, here's a peek at where 
we're heading.  We explored the road of "maybe lambdas should just be 
inner class instances, that would be really simple", but eventually came 
to the position of "functions are a better direction for the future of 
the language".

This exploration played out in stages: first internally before the EG 
was formed, and then again when the EG discussed the issues.  The 
following is my position on the issue.  Hopefully this fills in some of 
the gaps between what the spec currently says and what we say about it.


The issues that have been raised about whether lambdas are objects or 
not largely come down to philosophical questions like "what are lambdas 
really", "why will Java benefit from lambdas", and ultimately "how best 
to evolve the Java language and platform."

Oracle's position is that Java must evolve -- carefully, of course -- in 
order to remain competitive.  This is, of course, a difficult balancing act.

It is my belief that the best direction for evolving Java is to 
encourage a more functional style of programming.  The role of Lambda is 
primarily to support the development and consumption of more 
functional-like libraries; I've offered examples such as 
filter-map-reduce to illustrate this direction.

There is plenty of evidence in the ecosystem to support the hypothesis 
that, if given the tools to do so easily, object-oriented programmers 
are ready to embrace functional techniques (such as immutability) and 
work them into an object-oriented view of the world, and will write 
better, less error-prone code as a result.  Simply put, we believe the 
best thing we can do for Java developers is to give them a gentle push 
towards a more functional style of programming.  We're not going to turn 
Java into Haskell, nor even into Scala.  But the direction is clear.

Lambda is the down-payment on this evolution, but it is far from the end 
of the story.  The rest of the story isn't written yet, but preserving 
our options are a key aspect of how we evaluate the decisions we make here.

This is why I've been so dogged in my insistence that lambdas are not 
objects.  I believe the "lambdas are just objects" position, while very 
comfortable and tempting, slams the door on a number of potentially 
useful directions for language evolution.

As a single example, let's take function types.  The lambda strawman 
offered at devoxx had function types.  I insisted we remove them, and 
this made me unpopular.  But my objection to function types was not that 
I don't like function types -- I love function types -- but that 
function types fought badly with an existing aspect of the Java type 
system, erasure.  Erased function types are the worst of both worlds. 
So we removed this from the design.

But I am unwilling to say "Java never will have function types" (though 
I recognize that Java may never have function types.)  I believe that in 
order to get to function types, we have to first deal with erasure. That 
may, or may not be possible.  But in a world of reified structural 
types, function types start to make a lot more sense.

The lambdas-are-objects view of the world conflicts with this possible 
future.  The lambdas-are-functions view of the world does not, and 
preserving this flexibility is one of the points in favor of not 
burdening lambdas with even the appearance of object-ness.

You might think that the current design is tightly tied to an object box 
for lambdas -- SAM types -- making them effectively objects anyway.  But 
this has been carefully hidden from the surface area so as to allow us 
to consider 'naked' lambdas in the future, or consider other conversion 
contexts for lambdas, or integrate lambdas more tightly into control 
constructs.  We're not doing that now, and we don't even have a concrete 
plan for doing so, but the ability to possibly do that in the future is 
a critical part of the design.

I am optimistic about Java's future, but to move forward we sometimes 
have to let go of some comfortable ideas.  Lambdas-are-functions opens 
doors.  Lambdas-are-objects closes them.  We prefer to see those doors 
left open.