Gafter's closures

May 8th, 2007 by Hen

Sitting in Neil Gafter’s Closure talk, and reading Stephen Colebourne’s blog entries, I’m generally bouncing between optimism and disgust. The simple promise is nice, closures would be nice. However it seems much like generics, the devil is running rampant in the details.

One tiny thought. Using # is ugly Stephen, feels so wrong. Using => is semi-ugly Neil, feels like it’s a key for a dictionary. Especially with the { } wrapping. {String => int} - isn’t that a HashMap literal? :)

Me… I like |. { String | int }. Feels much nicer. Shame its bitwise OR already. Oh well - there goes my idea. I’ll throw “give us a Method object or Block object and can all the interfaces” into the crap pile too.

One thought I have is - how do closures work in languages on the JVM. Have Groovy et al been able to implement closures nice and easily, or would it be better to make the JVM support closures better and let Java live without closures.

Another thought… Gafter’s closure allows people to make it look like they’re defining new control statements. His suggestion for how to deal with that was to mouse over in your IDE… Yay, more IDE pushing. Bet ViM and grep’ll do it for me ;)

End of the day - Gafter’s seems the nicest one to use (from the biased view I’ve seen so far). I hate the use of the =>, I hate the many pages of subclauses and footnotes that I sense on this spec, but I love the idea of getting a map() function.

In true A A Milne style - when it looks nice it looks very nice, but when it looks ugly it looks fugly.

2 Responses to “Gafter's closures”

  1. Stephen Colebourne Says:

    We need to meet up at some point, so I can convince you of the rightness of FCM closures :-) Perhaps you’ll be at the date and time BOF tonight?

  2. Michael Nischt Says:

    IMHO, the main problems with closures are the ‘in place’ type definition. The simplest solution would be to use interfaces / classes. This looks like more writing at first, but since you can reuse them the code actually gets cleaner:

    interace Foo { Object foo(int a, String b) };

    Foo foo = aObjectWith#barSignatureMethod;
    Foo foo2 = antherObjectWith#barSignatureMethod;

    vs.

    Object#(int a, String b) foo = aObjectWith#barSignatureMethod;
    Object#(int a, String b) foo2 = aObjectWith#barSignatureMethod;

    Of course we need somthing to convert between compatible single method intefaces as it would be possible with closures, like an extended type-cast:

    interace Bar { String bar(int a, Object b) };

    Foo foo = ..
    Bar bar = (Foo as Bar) foo;