Then why can't: list.map( { (int x) => return x * 2; } ); be an inner class?

Oh, right, so if Gafter renamed 'closures' to 'inner classes' but kept everything else the same, you'd be happy? I'm really not sure what you mean otherwise. By the way, the return there is unnecessary as are the parens around int x.

The current control structures in Java are a bit odd in that apart from :? they don't return a value (straight from C).

Agreed, but it's generally a bit odd to have a method that has side effects also return a value.

About refactoring a closure into an inner class or vice-versa, I expect that to be automated by IDEs. People using closures need to know that closures are blocks of code, not anonymous methods or inner classes. If they worked like anonymous methods or inner classes they would be less useful.

You could write 101 Puzzlers on closures alone!

Perhaps, but they'd all be the same puzzler.

I think that named returns will be a lot clearer.

Languages should not force naming.

But we also need to ask the question, do we really need non-local return, break, and continue?

As long as the programmers likely to use closures are likely to think in terms of loops and side effects, return, break and continue are going to be useful. You could argue that closures should try to force them to think functionally instead, but that's not at all what Gafter is aiming for.

Scala drops beak and continue completely, because of their poor interaction with closures. Also Scala is consistent about the behaviour of return throughout the language (it uses yield for example when two types or return are required).

Scala drops break and continue because they are useless. Scala encourages composition, not messy for loops filled with ad-hoc renamed gotos like Java encourages. Scala has non-local returns. Returning within a closure in Scala is the same as returning from its enclosing method. I have obtained a NonLocalReturnException in Scala once, on purpose. More often, you don't even use the return keyword. I have 2268 lines of Scala, containing 16 mentions of 'return'.

I, like you, am not convinced that you can do a general escape analysis to track that { [closure] }.invoke() never returns. You can probably do simple cases and Neal has added some support with type Nothing.

Your map example could be an inner class, suppose that map was:

public interface List {
public List map( Method mapper );
public List forEach( ( Method mapper ); // see below for forEach comments
…
}

Then why can't:

list.map( { (int x) => return x * 2; } );

be an inner class?

Also the current inner classes interpretation of return can be used like a yield statement in Scala, which is nice. EG:

List strings = asList( "Hello", "World" );
List hStrings = strings.forEach( { (String s) =>
if( s.beginsWith( "H" ) ) { return s; }
return null;
} );

My forEach, in List above, only puts non-null items into its returned list, i.e. return yields the result. The current control structures in Java are a bit odd in that apart from :? they don't return a value (straight from C). This isn't usual in a functional language or even a more modern imperative language. Therefore I don't see much point in adding further support for a feature, control structures with no returned value, that is dated already.

I don't see that return as consistent in BGGA; the closure is much more like an inner class than anything else in the language, I think there will be enormous confusion when a closure is refactored into an inner class or vice versa. EG

String f() {
return new Object() {
public toString() {
String s = super.toString();
if ( s.endsWith( "A" ) ) { return "A"; }
return "Not an A";
} } + " Location";
}

and now refactor into a closure:

String f() {
return { () =>
String s = super.toString(); // not the same toString
if ( s.beginsWith( "A" ) ) { return "A"; } // Doesn't return to the same place
return "Not an A"; // Doesn't return to the same place
} + " Location"; // Never actually invoked, toString will be called on the wrapped closure!
}

This will be confusing. There are numerous places were the two examples above look like they do the same thing but don't!!! Sure I picked on toString, something that all objects have hence double the confusion. But you get the idea, this will not be easy to debug with a complicated example and the compiler won't help. I think people will tend to use the two, closures and inner classes, rather interchangeably. You could write 101 Puzzlers on closures alone!

The best you can say for the closure interpretation of return is that it muddies the water. I think that named returns will be a lot clearer. But we also need to ask the question, do we really need non-local return, break, and continue? Scala drops beak and continue completely, because of their poor interaction with closures. Also Scala is consistent about the behaviour of return throughout the language (it uses yield for example when two types or return are required).

Anywhere where you return, use this, write to local variables from the enclosing scope, continue or break is awkward to use an inner class with or without short syntax.

Anywhere where you don't care to see the types involved because they aren't interesting is annoying to use an inner class. list.map({ int x => x*2 }) is clearer than list.map(new IntToIntFunction(){ public int invoke(int x) { return x*2; } } ). Note that clear doesn't mean 'more explicit'.

The problem you mentioned is about tracing whether code returns or not, and isn't fundamentally about the syntax. If the closure { => return 5; } were tagged by the compiler as always returning, then the method that invokes it were detected to always invoke it, it would be possible to guarantee that the return happens, and the compile error you mentioned would disappear. In practice a big use case of closures is to pass them to other methods, so you'd lose this information quite quickly.

I look forward to seeing a real case where this is a problem.

"Re. non-local return: If you want this feature just add it to the language in general including inner classes, this way the whole language remains consistent – not different behaviour inside a closure to the rest."

It's not different behaviour inside a closure to the rest, it's identical. Return returns from the method it's used in. This does not change when it's inside a closure as a closure is not a method.

Barney, sorry if this conversation is considered noise.

Re. AbstractAction: I disagree, there are plenty of useful partial implementations that have more than one method that is potentially overridable.

Re. usefulness of closures: I can't think of an example where you couldn't use an inner class with short syntax where you can use a closure. The keys are short syntax, write to locals, and possibly non-local return, break, and continue – see below. I have nothing against improving inner classes with short syntax etc.

Re. Tennant: The closures proposal breaks Tennant, consider:

int f() { return 1; }

now lets wrap it:

int f() {
{ () => return 1; }.invoke();
// Syntax error here – doesn't return an int
}

Oops syntax error before the final }, since it doesn't return an int. Tennant uses this argument to argue against the return, break, and continue statements in his book. To sum up, Tennant himself rejects the return statement as being compatible with his principle. Hence closures don't give you Tennant's principle.

Re. non-local return: If you want this feature just add it to the language in general including inner classes, this way the whole language remains consistent – not different behaviour inside a closure to the rest. Using the BGGA syntax for an inner class with a named return:

String f() {
forEach(
new String[] { "hello", "world" },
{ (String s) => if ( s.startsWith( "h" ) ) { f.return s; } }
);
}

As you can see, exactly the same with an inner class as with a closure using named return. As I said before I think Neal is considering named returns for BGGA since the current syntax for the multiple types of return is confusing and hence I used named return above. I should spell this out; if you decide that non-local return is a good idea then add it to the whole language, not just the latest bolt on goody. Be consistent.

That is a fault with the AbstractAction type. It should be a one-method interface, or should be renamed to NotAbstractEnough :). You can easily create a one-method interface and a wrapper around AbstractAction without losing anything.

I agree about putting the field in the outer scope, but I'd rather not have the field if I can manage that.

You're not getting the point though. Closures are useful where anonymous classes are ridiculous. They are not a complete replacement.

"What is better about a closure?" Readability and 'wrapability'. Wrapability is what Gafter was talking about with his mentions of Tennent's Correspondence Principle. code should have the same meaning as { => code}.invoke(), in all cases. Wrapping code into an anonymous class makes it have a different meaning than it had before, making you have to do awkward things. Consider changing:

for (String s: new String[]{"hello", "world"})
if (s.startsWith("h"))
return s;

into a call to a forEach method that takes a closure/anonymous class. Using an anonymous class, and a simple method signature for forEach (void forEach(Action action);), the caller would have to throw an exception from inside the anonymous class and catch it from outside to achieve the early return. It's a similar story with break, continue, this and writing to local variables from the enclosing scope.

If you have a problem with forEach as an example, because there's already foreach in the language, think of another example.

jfeven aka java fonctors 7even

ps : Now i know why i hate java!proof of program !!!

A closure has two this pointers in the implementation, but you only see one from code. I'm not sure why you'd need a pointer to an object that has nothing more than a single method, from within that method, other than for recursion, which I'll soon address.

Saying that closures are a subset of inner classes is akin to saying that for loops are a subset of gotos. While it's technically true, it's not a very meaningful thing to say.

"There are a whole host of things you can do with an inner class that you can't do with a closure: inherit implementations"

It's a single method/function – how would it benefit from inheritance?

.."fields" – writing a closure that has a field is the same as writing a closure that uses a local variable from the enclosing scope, in terms of what you can do with it.

.."more than one method" – sure, you're talking about writing a class here, not about a block of code. Cars aren't appropriate for crossing bodies of water.

.."recursion". I once showed this Java code on a Java IRC channel, only to be told it wasn't Java:

System.out.println(new Object(){public int fac(int x) { return x<2 ? x : x*fac(x-1); } }.fac(5));

In other words, the closest you can do to a recursive lambda in Java is code that many people won't understand anyway. I think you can write a combinator to write a recursive lambda using the BGGA prototype, but I haven't quite understood how yet. The usual combinators you can use in lisp don't translate to typed languages particularly well.

A prototype is available: try it out! Like generics, the syntax is harsh at first but it becomes clear. The BGGA spec is actually quite elegant in many ways, and very powerful. You may or may not agree on elegance but you'll have more credibility after giving it an honest test-drive.

The difference is that the closure has one this pointer, it points to the enclosing class. An inner class has two this pointers, one that points to the inherited class and one that points to the enclosing class. Therefore a closure is, in a strict mathematical sense, not in a my opinion sense, a subset of an inner class. There are a whole host of things you can do with an inner class that you can't do with a closure: inherit implementations, fields, more than one method, recursion, etc. Some examples are here: http://www.artima.com/weblogs/viewpost.jsp?thread=202004.

Turn the question round, what can a closure do that an inner class can't. You will soon see that it is a subset of an inner class.

Howard.