Skip to main content

Yet Another Closures Proposal

Posted by alexanderschunk on January 17, 2008 at 9:47 AM PST

First: Getting rid of =>

Basically, when i read all the proposals, comments and pros and cons on closures in Java the first thing i would get rid of is the obviously redundant => declaration.

So in case of block statements the following would be allowed:

int x = 0;
int y = 3;
int sum:= x+ y;

As i understood it right, => has at least two meanings. It means return for functions and := or = in the other case.

Replace => by := for assignments

I would use := for assignments rather than => simply because := is more naturial to mathematicians and logicians and is usually used to describe an assignment in math and logics. This could be used as outlined above:

int x = 4;
int y = 3;
int z = 3;
int sum:=x+y+z; //assignment

Use a function keyword instead of {int, int => int} syntax

For the function declaration, i would suggest to use a keyword rather than a symbol. Why not invent a function keyword that has a similar meaning like => i.g.:

public int function add(int x, int y){
return x + y;

In the other case, i would use := instad of => because the arrow direction implies to read it left to right rather than right to left and there is no <= to represant the invert direction.

Use a block keyword to declare block statements

Rather than just simply type closures i would invent a block keyword that defines a block of anonymous statements:

//only valid for anonymous block statements, not be used in loops 

int x = 3;
int y = 4;


So with these language features you could write a simple to read Java code that is clear and understandable by everyone:

class MyClass{
//declare a function type
public int function add(int x, int y){
    return x + y;
public int function sub(int x, int y){
  return x - y;
public void function(List intList){
    for(int i = 0; i < 10; i++){
public static void main(String[] args){
  //declare a closures block
     int x = 4;
     int y = 3;
    System.out.println("x + y" + (x+y));

Related Topics >>


There seems to be a bug in the html keyword. Just add a function name and an int parameter type for the List in the addItem() function.

public void function addList(List intList){ for(int i =0; i < 10; i++){ intList.add(i); } }

Puh. Hard to get things right

Note: The list function sample should be run as follows:

public void function addItems(List intList){ for(int i =0;i < 10; i++){ intList.add(i); } }

i like this propsal btw ... i hate => shits they are SOOO rubish bla.

Haha. Look liks the ampersand symbol followed by the keyword int produces the integral symbol. So, mentally replace &int with: & int

One other thing I noticed as I read the second time... Where are the function variables and how do you invoke closures passed as method arguments? Classic examples: public void doSomething(int y, &int closure()) { return i + closure(); } // Inline doSomething(2, {return 3;}); // 5 // Variable &int a() = {return 4;}; doSomething(1, &a); // 5 Both of these are really the benefits of closures. I'm not sure what your idea is providing to be honest.

Adding keywords is necessarily difficult and makes backwards compatibility a challenge. Recall in JDK 1.5 the addition of the enum keyword was somewhat difficult for existing code. I doubt adding two keywords will be considered, but good luck with the proposal.

What's next? The DWIM* operator?

Why are people so obsessed to get his/her own favorite language construct into Java? If you want closures, use a language that has clean support for it (not just as an ugly afterthought).
This: "How can we add more (junk) to Java instead of fix already known problems" is a good sign that Java is on the way to become the COBOL of the 21st century.

Instead of adding complexity that make things simpler in some situation but more complicated overall, start reducing complexity!

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
-- Antoine de Saint-Exupery

Let's not forget that Java once started and was successful exactly because of that attitude!

*) the "Do what I mean" Operator is still missing from Java

This proposal is so clean, it does not even propose closures. Is this posting meant as a parody?

This is by far the cleanest Closures proposal I've read so far. I'm still not sure we should add Closures to Java but this proposal makes me give it more serious consideration.

A prototype of this syntax would go a long way in convincing me (and others) that Closures are a good thing.

why function as a keyword. Is it a reserved name? I'd like something more definitve, like oh, closure.

Very good proposal for a good closure syntax. I like it.

The add function would have been declared prior using it like a normal method. You could do it as follows:

public int function add(int x, int y){ return x + y; } public static void main(String[] args){ int x = 4, y = 4; int res = add(4, 4); }

Where in int res=int function add(x, y) is it made known to the compiler that res involves +? If I change x and y after int res=int function add(x, y) will the value that res returns change?

Actually its not really a proposal. Its just some suggestions to integrate closures into Java.

And using => for functions is not the way i want to programm. I prefer:

public static void main(String[] args){ int y = 5; int x = 4; int res = int function add(x, y); System.out.println("result: " + res); }

I like this syntax much better. It's actually readable. If I wanted more symbols in language, I'd use Perl.

I'm having difficulty seeing any part of this as a closure.

Please translate this to your proposal:

public static void main(String[] args) {
. . int y=5;
. . {int => int} addY={int x => x+y};
. . System.out.println(addY.invoke(2));
. . y=10;
. . System.out.println(addY.invoke(2));

What you showed in your last comment is a different syntax for a static method, and not a closure.

I suggest you spend some time reading the Wikipedia article about closures, and trying them out in various languages.

Basically, when i read all the proposals, comments and pros and cons on closures in Java the first thing i would get rid of is the obviously redundant => declaration.

Wrong approach. The right one would be to get rid of all the closure fanboyz.