Closures in Java Vs C# (Non-Local Gotos, Custom Syntax)

Sun is looking to add closures into an upcoming version of the Java language. Partial closures are already supported through the heavyweight inner classes feature. Interestingly, full closures were available in a prerelease version of Java and then removed due to user feedback.

I spoke to Gilad Bracha at the Lang.Net Symposium about Sun’s apparent disregard for functional programming such as closures. The last wave of new features introduced included virtually no functional programming constructs. I alluded to Guy Steele’s piece on Objects Have Not Failed. Gilad revealed his own preference for closures, saying that he was on my side in this matter and has been advocating these features at Sun for years. I yesterday noticed his post Achieving Closure, which confirmed his earlier remarks.

Sun’s Closure Proposal proposes two new features, function types and closures. These new features are almost a superset of what C# currently offers. Each language takes the other’s innovations and tries to outdo each other, but with a different syntax.

The new “function types” are structural just like C++ function pointers, not nominal as delegates are in C# and .NET. Structural typing in C#, however, is possible through the used of parametrized types (generic delegates) and special conversions for method groups. LINQ., for example, uses generics (eg, Func<A1,A2,T>) to simulate structural typing.

Java closures can read and write to locals, captured from the enclosing scope, just as in C#, but there are numerous differences from C#.

• Closures can be named, but in Java, I suspect, it’s implemented as an assignment of an anonymous function to a local variable; however, named closures may be treated more like regular methods, such as how return statements are handled.
  
• Java closures goes one step further than C# closures by allowing non-local break, continue, and return statements just as in Smalltalk and Perl.
  
• In addition, closures can be use to extend Java syntax in a clean way, so that developers can create, for example, their own for, while, if equivalents in an manner similar to Perl. Basically a function that takes a closure as an argument can eliminate the parentheses surrounding the argument list.  

In C#, List<T>.ForEach() with an anonymous method isn’t quite the same as foreach, because there is no way to exit the operation prematurely except through an expensive exception. This was one of my reasons for advocating lightweight exceptions in the past. The Java proposal would make it possible to return, break and continue from inside the closure. It’s not entirely perfect reimplementation, because breaks and continue only exit standard Java looping constructs.

The new custom syntax support could have eliminated the need for a custom lock and using keyword in C#. Java’s approach effectively refutes an argument made by Anders in the last PDC panel about the downsides of creating new syntax—that the new syntax would result in the inability to understand and maintain someone else’s code if hygienic macros were added (see C++). The proposal takes what can already be achieved through closures anyway and compresses the syntax further into a more readable version. Instead of writing the following:

FireAndForget (delegate {
   // Do action
});

One can simply write

FireAndForget {
   // Do action
};

Comments

[Eric TF Bat]

Lua has a syntactical shortcut where you can remove the parens from a function call if it has only one argument, provided the argument is a string "like this", an array {like, this} or a Perl-style multi-line 'heredoc' string [[like
this]]. It means that syntax like print "Hello, world" is legal; you don't have to say print("Hello, world"). Sounds like this Java syntax is a step in that direction; I think it makes things a little more readable, and that's a Good Thing.