Will closures carry as much complexity as generics?
I don't think closures will warrant 300 page books, but that doesn't mean they're as easy as they sound. Pop quiz: based on Neal's proposal, will the following code compile?
{ Object => String } closure =
{ String s => new Object(); }
The answer is in the comments. So far as closures go, that's a relatively simple example. Then again, the non-closure version isn't exactly simple either.
11 Comments:
I won't be surprised to see a book about closures. In my recollection there was an O'Reilly's book on threads, which is like one class and an interface in those times.
What is still puzzling me is why did they changed syntax to notation with => ? Maybe you can pull it from Neal somehow...
I could be wrong, but isn't your example wrong. I read this text as declaring a new function called closure that has an Object argument and returns a String but it is assigned to a function that accepts a String and returns an Object. IE argument and return types swapped. I can't be sure since I find the syntax difficult to read - can you check with Neal Gafter?
I suspect there will be a lot of confusion with the Neal Gafter form of closures. In particular why their behaviour isn't like inner classes and why the syntax is so un-Java like.
Yeah, the answer is, "no, the code won't compile." I meant it as a quiz.
Here is another example of the difficulty. Do you know what this will do?
interface F { int call(); }
...
static int doubleIt( F f ) { return 2 * f.call(); }
...
static int halveIt() {
int x = doubleIt( { return 42; } );
return x / 2;
}
Are you sure you know what this does, what about the closure conversion? Is it the same as:
static int doubleIt( {=> int} f ) { return 2 * f.call(); }
...
static int halveIt() {
int x = doubleIt( { return 42; } );
return x / 2;
}
Even if you do know the right answer, is it clear?
Personally I can feel another 101 puzzlers coming on :)
Ha ha. And you didn't even get into bottom types. ;)
Sorry - I don't understand the difficulty with Bob's original code snippet.
The closure declaration seems to require a String to be returned, while the closure itself is returning an Object - of course that won't work!
To me, this is basically analogous to a method being declared to return String, but the code attempt to return Object - of course that won't work!
The point is structural typing marks a significant and potentially confusing change to the type system. You and I may get it, but I suspect we both get generics, too. Not everyone is in that boat. Finally, you compared closures to methods, but closures support contravariant parameter types while methods do not.
I agree with Bob re. the contravariance. EG what this will do?
interface F2 { int call( Integer i1, Integer i2 ); }
...
F2 add = { Number n1, Number n2 => n1.intValue() + n2.intValue(); };
Are you sure you know what this does, what about the closure conversion? Is it the same as:
{ Integer, Integer => int } add = { Number n1, Number n2 => n1.intValue() + n2.intValue(); };
Even if you do know the right answer, is it clear?
Syntax error: you forgot the name of the closure's parameter.
Actually, function types are simply shorthand for interface types. The "structural typing" is inherited from generics.
Oops. Fixed.
So, how are closures coming along, exactly?
Specifically: What are the odds that BGGA closures will hit java7 or java8?
How about CICE? What's going on there?
Whatever BGGA might have on CICE, CICE will lead to... maybe 4 puzzlers, tops.
Post a Comment
<< Home