First-class methods would be a win, but the syntax leaves a little bit to be desired. Closures would be much more of a syntactic eyesore if they A) had context-based type inference on the arguments, so that if I'm passing a closure to a method that expects (String, String) -> as its type I don't need to redeclare the variable types and B) allowed for embedded expressions rather than requiring them to be full function definitions with a "return" statement in there. Unfortunately, the FCM proposal doesn't allow either of those.
To use their example, it should be much more like:
There's no technical reason you couldn't do the former in Java (and their proposal seems to infer the return type just fine?), but no one involved with the Java language seems to really value conciseness.
Something tells me these are going to be as bad as PHP's closures; you can't just tack on lambdas at the last minute, it has to be part of the language design initially (no?)
As someone who's implementing closures in a JVM-based language, I can tell you there's no technical limitations on the JVM side: there are decisions to be made as to how you want to implement them, but it's certainly doable with enough compiler magic.
That said, the BGGA proposal is a bit of a disaster in my opinion: the distinction between "restricted" and "unrestricted" closures, along with non-local returns, just makes no sense. My assumption is that they want to use closures for things like control structures, which they're just totally inappropriate for, rather than as just anonymous functions, which is what they really ought to be.
Basically, it's what they did with generics: take a relatively sensible concept, then add a bunch of baroque edges to it for no good reason. Honestly: => and ==> are almost equivalent things with totally different semantics as far as control structures? Really?
People are going to understand that about as well as they understand why they can't add an Object to List<? extends Object>, or why they can't pass a List<String> back from a method that says it returns List<Object>. By which I mean, not at all.
Python had them tacked on after the fact (version 2.0 as I recall, or was it 2.2?), they work pretty nicely IMO, as long as you treat functions as first class objects the whole time you're ok.
The proposed system at http://javac.info/ is a little weird and unconventional but it could be promising. It really all depends on what Sun/Oracle decides to do with the language as JDK7 seems to be in limbo at the moment.
[+] [-] fadmmatt|16 years ago|reply
I taught my advanced compilers class how to compile Scheme directly to Java by using them to implement lambda:
http://matt.might.net/articles/compiling-to-java/
In fact, as the link above points out, anonymous classes are flexible enough to express the Y combinator, allowing "recursion-less recursion" in Java.
[+] [-] statictype|16 years ago|reply
If you look at it that way, anything from generators to continuations can be 'simulated' using enough layers of class definitions.
[+] [-] bokchoi|16 years ago|reply
http://docs.google.com/Doc?id=ddhp95vd_0f7mcns
[+] [-] akeefer|16 years ago|reply
To use their example, it should be much more like:
Collections.sort(list, \str1, str2 -> str1.length() - str2.length());
instead of:
Collections.sort(list, #(String str1, String str2) { return str1.length() - str2.length(); });
There's no technical reason you couldn't do the former in Java (and their proposal seems to infer the return type just fine?), but no one involved with the Java language seems to really value conciseness.
[+] [-] bokchoi|16 years ago|reply
http://www.javac.info/closures-v06a.html http://www.jroller.com/scolebourne/entry/closures_in_jdk_7
[+] [-] natmaster|16 years ago|reply
[+] [-] jshen|16 years ago|reply
Scroll down to method literals
[+] [-] bokchoi|16 years ago|reply
[+] [-] dschobel|16 years ago|reply
[+] [-] jcapote|16 years ago|reply
[+] [-] akeefer|16 years ago|reply
That said, the BGGA proposal is a bit of a disaster in my opinion: the distinction between "restricted" and "unrestricted" closures, along with non-local returns, just makes no sense. My assumption is that they want to use closures for things like control structures, which they're just totally inappropriate for, rather than as just anonymous functions, which is what they really ought to be.
Basically, it's what they did with generics: take a relatively sensible concept, then add a bunch of baroque edges to it for no good reason. Honestly: => and ==> are almost equivalent things with totally different semantics as far as control structures? Really?
People are going to understand that about as well as they understand why they can't add an Object to List<? extends Object>, or why they can't pass a List<String> back from a method that says it returns List<Object>. By which I mean, not at all.
[+] [-] dschobel|16 years ago|reply
[+] [-] jrockway|16 years ago|reply
[+] [-] kingkilr|16 years ago|reply
[+] [-] adatta02|16 years ago|reply
[+] [-] tjsnyder|16 years ago|reply