Re: a convert to lambda-ism
On Mon, 15 Nov 2010, Joshua Cranmer wrote:
On 11/14/2010 09:22 PM, Lew wrote:
I've been perusing
<http://cr.openjdk.java.net/~mr/lambda/straw-man/>
For the first time in the closures debates, I'm a fan of lambda
expressions in Java now.
The best thing I can say is that it doesn't have BGGA's fanatical devotion to
non-local control flow idioms.
Yes. I literally punched the air when i read:
There is no non-local transfer of control in this proposal, in contrast
to BGGA.
I thought i was the only one who thought the 'return returns from the
enclosing scope' was batshit insane.
Those made a lot of the stuff just plain complex and confusing, and that
alone was enough to sink the proposal for me.
Amen to that, brother. Also, it had maximally horrid syntax. Even
Reinhold's 'strictly provisional' syntax is better!
I'm not crazy about the syntax, but then again, function pointers have
never had stellar syntax. int (*fp)(int, int), anyone? :-) The ability
to just have single expressions I'm not entirely sure about-- #() {
return x + x; } isn't much longer than #()(x + x), and is certainly
somewhat easier to read.
The terseness lends itself to the typical higher-order-function uses,
like:
List<String> names;
List<Integer> lengths = names.collect(#(String s) (s.length()));
Adding the return to that makes it noticeably, although of course by no
means fatally, clunkier.
Another minor syntactic note is that introducing the new keyword
`shared' (or rather, introducing it non-breaking ways (!)) seems
unwarranted. If the idea is to limit to the enclosing scope, you could
probably have the same effect if you reused the keyword `public'.
Agreed.
And i'm surprised non-shared closed-over variables aren't required to be
declared final, but must only be 'effectively-final'. That seems
un-javalike.
In terms of major semantic concerns, the big question to me is how to
handle the types. How they are actually implemented does leave major
concerns other some generics interactions due to erasure.
Could you expand on that? I don't know how to even begin thinking about
the interaction with types.
Mind you, having seen what's happened to the type system around
invokedynamic, i am no longer sure that such concerns are actually a
roadblock to implementation, sadly.
I'm also not sure about the extensions method section. While I have had
instances where I would have liked to use it, it's never been a
dealbreaker.
Given that we won't be able to add lambda-aware methods to existing
collection interfaces, because that would break all existing code which
implements them, extension methods are the only way of being able to write
the example i give above, or do anything along those lines (map, filter,
reduce, and friends). Having lambdas but not being able to do those things
would be agonizing.
Also, i really don't like the implicit function conversion. I appreciate
that there are millions of places where we'd like to use first-class
functions where we currently use these 'SAM' (Single Abstract Method - i
had to look it up) types, but i don't think we should be catering to that
in the language. For the most part, the classes which currently demand SAM
types are ones in the standard library (Collections, Arrays, Thread) which
could easily be enlarged to take lambdas too. Where there are interfaces
which we'd like to expand, we can use extension methods:
package java.util.concurrent;
public class ExecutorService {
public static Thread newThread(ThreadFactory self, #void() fn) {
return self.newThread(new Runnable() {
public void run() {
fn();
}
});
}
}
import static ExecutorService.newThread extends ThreadFactory; // my suggestion
ThreadFactory factory;
Thread t = factory.newThread(#() {doStuff();});
There are tons of other things extension methods would be useful for. I
think once you had them, you'd wonder how you ever lived without them. For
instance, you'll immediately be able to say:
import java.util.List;
import static java.util.Collections.sort extends java.util.List;
List things;
things.sort();
Wouldn't that be nice?
tom
--
We don't contact anybody or seek anybody's permission for what we do. Even
if it's impersonating postal employees. -- Birdstuff