This last code example is a pain o.o If implemented neatly, closures would be a great improvement for Java.
Ricky Clarkson
Read int => as "takes an int and gives". So: { int, int => int } takes two ints and gives an int. { int => { int => int } } takes an int and gives something that takes an int and gives an int. In Haskell, both would normally (yes, I know about tuples) look like this: Integer -> Integer -> Integer, which you can either read as something that takes 2 Integers, or as something that takes an Integer and returns something that takes an Integer and returns an Integer. The second Java example just seeks to emulate that. I doubt it would be usual code. For when you want to turn a { X, Y => Z } into a { X => { Y => Z } }, you'd probably rather have a 'curry' operator or method. I'll rewrite the last two lines of the blogged example as such: System.out.println(curry( {int x, int y => x + y } ).invoke(3).invoke(4)); I avoided assigning to a variable because the variable would have been of type { int => { int => int } }, and clearly wasn't really relevant - I'd rather have type inference. Thankfully, my current favourite language, Scala, has type inference. :)
By the way, is that really a new concept or merely a alias syntax for an abstract class, anonymously instantiated? The latter'd be pretty simple to implement, I suppose.
I assume you meant to say 'anonymous class'? It's the latter. Closure types are technically Java interfaces with an appropriate invoke() method. A closure expression is then analoguous to instantiating an anonymous class.

New comment