Re: new Java lambda syntax
On 11/09/11 13:06, Tom Anderson wrote:
On Sat, 10 Sep 2011, Steven Simpson wrote:
* 'effectively final' - A non-final local variable can be immutably
captured by a lambda, so long as it's shown not to be assigned to
subsequently.
Seems sensible. I would have been happy with a requirement for
explicit finality, but i recognise that many people would have been
annoyed by it, and i don't think this introduces any danger. Any idea
how hard it is for the compiler to prove that the variable cannot be
modified?
Hmm, it's more strict than I thought (but easier to compile). It seems
you have to be able to add final to the variable declaration. This
compiles fine:
void func() {
int i = 0;
Runnable action = () -> { System.out.println(i); };
}
....but any assignment to 'i', before or after creating 'action',
prevents 'i' from being effectively final.
Hardly a disaster. :-)
* 'long this' - In the body of a lambda, 'this' has the same meaning
as it would in the enclosing scope. It does not refer to the
object that ultimately fulfils the lambda.
Also seems sensible. Are there any cases where you would want to refer
to the lambda object itself? I'm sure people will come up with them
once lambdas come into use. Will there be any way to get hold of such
a reference?
Some corner cases came up, along with some work-arounds. They were
probably recursive. I think assignment rules were altered slightly so
that a lambda body could refer to itself:
Runnable x = () -> { x.run(); };
It was deemed okay to allow this because you can be certain that x will
be ready before it is run.
* 'throws T' - A set of exceptions can be expressed as a generic
type parameter, so they can be relayed from the lambda's signature
to the signature of the method that calls it.
Oh, cool.
Yes, except I'm not sure how useful it will be in practice with
concurrent APIs. With a serial contract, like a library version of the
for-each loop, it's clearly useful:
interface Block<E, throws T> {
void apply(E val) throws T;
}
static<E, throws T> void forEach(Iterable<E> coll, Block<E, T> block) throws T {
for (Iterator<E> iter = coll.iterator(); iter.hasNext(); ) {
E elem = iter.next();
block.apply(elem);
}
}
Now the forEach method can generically throw the same set of exceptions
T that the block itself can throw.
But if there is no serial guarantee on invoking the block, you have to
choose whether you return arbitrarily just the first exception thrown,
or pack them into some structure, or something else. I've a feeling
that, most of the time, such methods will require the SAM type to throw
nothing, so <throws T> won't get used.
It could be argued that these restrictions seem to reduce lambdas to
just a shorter syntax for certain anonymous inner classes. However,
I think there's an aspiration to implement them more cheaply than
normal objects.
I'd be happy with them actually being syntactic sugar for anonymous
classes (i am quite unsophisticated my tastes!). The VM boffins could
then focus on making anonymous classes cheaper in general.
I think they don't foresee such savings for anon classes generally,
because they potentially have fields and multiple user-defined methods.
When you're certain such complexities don't exist, which is the case for
lambdas, certain optimizations become possible.
There are no automatically generated families of function types
(yet), so you have to rely on SAM (single abstract method) types.
Lambdas are just a syntactic construct until you've expressed or
implied the SAM type, with an assignment, initialization or a cast.
Oh, wait, what? Wow. There's no function type? So you can *only* use
lambdas as SAMs? Have i understood that correctly? That's kinky.
You seem disturbingly excited by that! :-) Here are some arguments
about it (not necessarily mine):
* Function types would introduce a form of structural typing, which
is a little alien to Java. We saw a thread here just a few days
ago ("simple method to simulate function pointers in java"), where
someone was hand-crafting generic function types, and some of the
advice was just to define interfaces per situation, partly because
it documents better, and partly because it's more idiomatic for Java.
* Function types could be added in such a way that they would be SAM
types, so if you can get lambdas to work with SAM types (which
you'd probably have to do anyway to take advantage of old APIs),
they should automatically work with function types added later.
* A limited number of generic SAM types are being defined to extend
the Collections API. They will probably serve as well as function
types in the most common cases.
* If a lambda is always typed as a SAM, how you invoke it is settled
- it's the name of the SAM's method, of course. I recall seeing
proposals where you could write obj(args), or obj.(args), or
obj.invoke(args), where obj was a function type. Leave it as a
SAM, and you don't have to make a decision about that.
You say 'yet' - can we expect function types before it's finished?
IIRC, no plans for Java 8 - back burner, I think. ISTR some
difficulties arose, so maybe they decided they needed more time for
something deemed not essential.
--
ss at comp dot lancs dot ac dot uk