http://jroller.com/page/scolebourne?entry=first_class_methods_java_style

FCM is located between CICE and BGGA, and we believe that it address most of your concerns listed above. We’d love to receive your feedback.

As to what is surprising I agree with John. I was surprised when I read about how break and continue could be used within closures (BGGA), as this is something I’m not used to from Lisp. After having understood their usage, I think I would be even more surprised if was allowed to use break and continue after the loop context had exited. It doesn’t have a meaning, it’s like a control flow analogy to a following a null pointer: it makes no sense and we should be made aware of the error.

I believe the currentl proposal requires the compiler to refuse to compile code where it can tell that this will happen. Specifically, if closure’s type extends RestrictedClosure (e.g. because it is intended to handle asynchronous closures like the Runnable interface) I think you will not be able to compile any code featuring a break or continue that would cause a loop *outside* the closure itself to terminate.

I’d be interested in seeing some cases where the compiler can’t tell this, then we’ll know how common this exception will be.

Rusty, you say:
“First of all, I’m not sure I like that return returns from the enclosing scope rather than from the closure itself. That’s a surprise.”

Well, that’s a consequence one of Neal’s initial design goals. The idea was specifically to avoid a different kind of surprise The idea is if you take code that is not inside a closure and move it into a closure, it should mean the same thing. He blogged about it here, Tennent’s Correspondence principal, which explains the reasoning better than I can:

http://gafter.blogspot.com/2006/08/tennents-correspondence-principle-and.html

That page also contains a proposal for a yield syntax ( ^value ) but they have since dropped that - I am not sure why.

If you want to understand the proposal in more depth, I recommend reading Neal’s blog in chronological order. I’ve been following along and it has been enlightening.

#1: When I first read about Java inner classes, the restriction that a (non-static) inner class can only refer to final variables in the enclosing scope outraged me. “Either do lexical scoping right or leave it out!” I thought, coming as I do from a Lisp background where lexical scoping works for both mutable and immutable variables, and the compiler figures out which are which and how to manage the implementation.

Now I shrug and live with the restriction; the compiler complains when I break it, and I work around the problem. (The general workaround is to have a trivial “box class” that contains just one public instance variable, which is more or less what Lisp compilers do when they decide they have to.)

#2: public means “accessible out of the obvious scope”. It’s meaningless to attach the normal out-of-class semantics to local variables anyhow, so attaching them here is not really a Big Deal. We already have multiple meanings of final without too much problem.

#3: Strong static typing has nothing to do with whether your language has type inference. Java versions up to 1.4 didn’t do type inference; you had to write out every type name explicitly. Generics require the compiler to do a modest amount of type inference, and there are strongly statically typed languages where the compiler does all the type inference; in ML, you never need to mention an explicit type within a structure (the analogue of a class) except where you are doing ad-hoc overloading of operators, as with floating-point + vs. integer +. And ML is even more statically strongly typed than Java is, as it doesn’t have the null hole.

#4: The non-local-transfer exception is really quite unavoidable. Remember that beside being functions, closures are first-class objects, so they can be preserved in global variables or inside other objects (indeed, this is one of their common uses). When a closure created within a loop does a break or continue, and the loop is already complete, there really is no non-surprising thing to do, but silently returning (with what value, anyhow?) is much more surprising than throwing an error.