{"id":441,"date":"2011-06-14T19:55:00","date_gmt":"2011-06-14T19:55:00","guid":{"rendered":"http:\/\/www.javacodegeeks.com\/2012\/10\/java-lambda-syntax-alternatives.html"},"modified":"2012-10-21T19:49:42","modified_gmt":"2012-10-21T19:49:42","slug":"java-lambda-syntax-alternatives","status":"publish","type":"post","link":"https:\/\/www.javacodegeeks.com\/2011\/06\/java-lambda-syntax-alternatives.html","title":{"rendered":"Java Lambda Syntax Alternatives"},"content":{"rendered":"
The discussion on the lambda-dev mailing list has started to address the issue of what the Java language syntax for lambdas \/ function literals ought to look like. Let\u2019s look at a slightly non-trivial example and try to tease the issues out.<\/p>\n

The Perl people have a nice example of something which uses function references in a somewhat functional way \u2013 they call it the Schwartzian Transform (but I believe it\u2019s originally a Lisp trick sometimes called decorate-sort-undecorate). As there are just us JVM chickens here, I rewrote it in Clojure (it\u2019s actually one of my examples in Chapter 9 of the book).<\/p>\n

Here\u2019s a snippet of Clojure code which defines a function to perform the Schwartzian transform. Basically, it provides a very simple way of sorting a list based on an auxiliary function (called a \u201ckeying function\u201d) provided by the caller.<\/p>\n

(defn schwarz [x f]\r\n  (map #(nth %1 0)\r\n       (sort-by #(nth %1 1)\r\n                (map #(let [w %1]\r\n                     (list w (f w)) ) x))))\r\n<\/pre>\n
The code is doing three separate steps \u2013 creation of a list consisting of pairs (the original values paired up with the value obtained by applying the keying function to the original values), then sorting the pairs based on the values of the keying function. Finally a new list is constructed by taking only the original value from each pair in the sorted list-of-pairs (and discarding the keying function values).<\/p>\n
What might this look like in the various proposed Java syntax variants? Let\u2019s take a quick look at each one (note that because Java\u2019s type system is much more static, a lot of our type declarations are more than a little long-winded):<\/p>\n
\/\/ Strawman, with round brackets for single-expression lambdas\r\npublic List<T> schwarz(List<T> x, Function<T, Pair<T,V extends Comparable<T>>> f) {\r\nreturn map(#(T w)(makelist(w, f.apply(w))), x)\r\n       .sort(#(Pair<T, V extends Comparable<T>> l)(l.get(1)))\r\n       .map(#(Pair<T, V extends Comparable<T>> l)(l.get(0)));\r\n}\r\n\r\n\/\/ Strawman, with braces for all lambdas\r\npublic List<T> schwarz(List<T> x, Function<T, Pair<T,V extends Comparable<T>>> f) {\r\nreturn map(#(T w){makelist(w, f.apply(w))}, x)\r\n       .sort(#(Pair<T, V extends Comparable<T>> l){l.get(1)})\r\n       .map(#(Pair<T, V extends Comparable<T>> l){l.get(0)});\r\n}\r\n\r\n\/\/ BGGA\r\npublic List<T> schwarz(List<T> x, Function<T, Pair<T,V>> f) {\r\nreturn map({T w -> makelist(w, f.apply(w))}, x)\r\n       .sort({Pair<T, V extends Comparable<T>> l -> l.get(1)})\r\n       .map({Pair<T, V extends Comparable<T>> l -> l.get(0)});\r\n}\r\n\r\n\/\/ SotL\r\npublic List<T> schwarz(List<T> x, Function<T, Pair<T,V>> f) {\r\nreturn map(#{T w -> makelist(w, f.apply(w))}, x)\r\n       .sort(#{Pair<T, V extends Comparable<T>> l -> l.get(1)})\r\n       .map(#{Pair<T, V extends Comparable<T>> l -> l.get(0)});\r\n}\r\n\r\n\/\/ Redmond\r\npublic List<T> schwarz(List<T> x, Function<T, Pair<T,V extends Comparable<T>>> f) {\r\nreturn map((T w) -> {makelist(w, f.apply(w))}, x)\r\n       .sort((Pair<T,V extends Comparable<T>> l) -> {l.get(1)})\r\n       .map((Pair<T, V extends Comparable<T>> l) -> {l.get(0)});\r\n}\r\n<\/pre>\n
How to evaluate them? My criteria are:
 
<\/div> <\/div><\/p>\n
    \n
  1.     Needs to start with a visible identifying mark, so that lambdas stand out from the surrounding code. The # is a handy character for this.<\/li>\n
  2.     Needs to use the {} delimiting syntax. Closures are a kind of block, so they should be block-like in code.<\/li>\n
  3.     Needs to be all in one piece, so the syntax has a visual consistency and the lambda appears as a single unit.<\/li>\n
  4.     Preferably, needs to have a specialized short form for function literals which take no parameters (nullary lambdas).<\/li>\n<\/ol>\n
    Based on these criteria, Redmond is the worst possible choice for me \u2013 and my experience writing Scala for the book bears this out \u2013 I found Scala\u2019s function literals much harder to use without problems than those in other languages. BGGA is a little better, but I don\u2019t like the lack of a simple identifying mark that tells me \u201cHello! I\u2019m a lambda\u201d.<\/p>\n
    This brings it down to a choice to between SotL and Strawman with always-brace. The choice of these two is somewhat arbitrary. Strawman-always-brace looks, to my eyes like a true Java method declaration, but with the \u201cmagic name\u201d # \u2013 whereas SotL is genuinely new syntax, but feels closer to the Redmond and BGGA styles \u2013 so could well be an acceptable compromise for developers who are comfortable with those forms.<\/p>\n
    Pulling it all together, my preferred choices are:<\/p>\n
      \n
    1.     SotLhttp:\/\/www.blogger.com\/img\/blank.gif<\/li>\n
    2.     Strawman-always-brace<\/li>\n
    3.     BGGA<\/li>\n
    4.     Strawman-single-expression-round<\/li>\n
    5.     Redmond<\/li>\n<\/ol>\n
      Please use the comments (below or at the original source<\/a>) to tell us what you make of this issue. Of course, this won\u2019t be in Java 7 \u2013 but it\u2019s not too early to start thinking about Java 8 and the future.<\/p>\n
      Reference: <\/i><\/strong>Lambda Syntax Alternatives<\/a> from our JCG partners<\/a> at the Java 7 Developer Blog<\/a>.<\/p>\n
      Related Articles :<\/i><\/strong><\/div>\n