They DO capture all variables from lexical scope. They then add the compiler limitation where the compiler will understand what you mean but refuse to compile it if you access a mutable local variable. For good reasons.
control flow, if I can presume you mean "long" returns / breaks / continues, have been left out for now because they can most easily be added later, and are a gigantic source of complexity. (think about it - what happens when you 'long return' out of a method that's already long exited, because the closure has been stored in a field someplace and executed later? Or, what should happen if a closure that is run in another thread tries to 'break' out of a still running for loop? That for loop is now running in another thread compared to the closure, so - should two threads dovetail their way through a for loop? That's going to be hard to make work! In practice you need to add the notion of 'unescaping' closures to either the type system or the compiler's analysis. You see how the complexity starts adding up quickly). You're technically right in that the term 'closure' is being slightly overextended here. However, just like "HTML5" doesn't actually mean you use features from the HTML5 spec, "AJAX" does not mean you use XML (or even an XmlHttpRequest object), and "javascript" has nothing to do with "java", terms in the programming world change meaning all the time. In java land, "closures" currently means "code blocks". I'll join you in lamenting the loss of clarity caused by this confusion, but, it happened. No way to put this genie back in its box. On Jun 1, 8:04 pm, Alexey Zinger <[email protected]> wrote: > So basically, this is just syntax sugar around single-method anonymous inner > classes. I'm not saying it's the end of the world, but they aren't closures > strictly speaking. Everything I ever read about what differentiates closures > from anonymous inner classes (control flow, lexical scoping) is untouched as > compared to what we do already with more verbose syntax. > > Alexey > 2001 Honda CBR600F4i (CCS) > 2002 Suzuki Bandit 1200S > 1992 Kawasaki > EX500http://azinger.blogspot.comhttp://bsheet.sourceforge.nethttp://wcollage.sourceforge.net > > ________________________________ > From: Reinier Zwitserloot <[email protected]> > To: The Java Posse <[email protected]> > Sent: Mon, May 31, 2010 6:08:52 AM > Subject: [The Java Posse] Re: Good gosh J7 lambdas/closures are looking worse > by the day > > Here's a very short rundown on the official syntax, with a link to the > last known proposal at the end. The current status quo isn't, as far > as I know, 100% the same as the 'official' proposal, because a new > version of the spec hasn't been released in months. There's also been > an encyclopedia's worth of traffic on concerns and disadvantages on > lambda-dev, but none of those have been discussed by Mark Reinhold, > Alex Buckley, Maurizio Cimadamore, or Brian Goetz, who all seem to be > involved in writing specs and implementations. > > closures themselves come in two flavours. Either form is an > expression, whose type is a closure type: > > inline expression form: > > #(parameter list) ( expression ) > > block form: > > #(parameter list) { any number of statements; } > > The first form is syntax sugar for: > > #(parameter list) { return expression; } > > So, you can write: > > Object plusClosure = #(int a, int b) (a+b); > > which is the same thing as writing: > > Object plusClosureLongForm = #(int a, int b) {return a + b;}; > > [Justification: In practice blocks have to be written in standard > style, so, line breaks after opening brace and before closing brace, > lest it look like a semi-colon party, but that means all closures are > multi-line, even very simple ones, such as plus, so, there's a short- > hand form if you can express the body of a closure as a single > expression. Also, inferring parameters is essentially impossible but > inferring return type and checked exceptions isn't, and closures > should be simple (and syntactically very brief), hence the inference.] > > Note that 'long returns' doesn't work, you can't break or continue a > loop that your closure definition is in, nor can you return from the > method that your closure definition is in. > > Also, the closure captures all variables from outer scope but you > can't actually interact with them unless they are final or effectively > final (effectively final = not marked final, but wouldn't cause an > error if they were marked as such). > > The full type signature of a closure consists of 3 properties: > > A) Parameter List. Read from the actual parameter list in the closure > definition. > B) Return Type. Inferred from the return statement (block form) or the > type of the expression (inline expression form) > C) (checked) throwables thrown. Inferred. > > Obviously assigning a closure to an "Object" variable isn't very > useful. There are two useful type concepts you can assign them to, > function types and SAMs. > > Function Types. These look like this: > > #int(int, int)(throws IOException | SQLException) plusClosure = #(int > a, int b) (a+b); > > [yes, good lord, that's some horrible syntax, I know - also the > official 1.5 spec on function syntax is riddled with errors particular > in regards to the throws syntax; alternatives that also might be valid > depending on where you look in the spec is "(throws IOException, > SQLException)" and just "(IOException, SQLException)". > > justification: Without the extra parens around the throws clause the > parsing rule wouldn't terminate which isn't legal in LL(k) grammars > such as the ones used by most java parsers including javac. Or > something. I was a bit fuzzy on this, you may want to check lambda- > dev.] > > function types can be 'executed' by using the dot. For example: > > assert 15 == plusClosure.(5, 10); > > [justification: In java, method names and variable names are separate > namespaces, so just closureVarName() would be looking in the wrong > namespace!] > > Closures can also be assigned to SAM types. A SAM type is any type > that is (1) abstract and (2) has only one undefined method in it. In > other words, any interface that mentions only 1 method, and any > abstract class where all but 1 method has an implementation. Like > FileFilter and Runnable. Thus, this would work just fine: > > Runnable r = #() {System.out.println("Hello, World!");}; > r.run(); //Will say hi to world. > r.(); //This wouldn't be legal; r is a Runnable, not a #()(). > > The mechanics for realizing that the above closure declaration, which > is of type #()(), can be 'fitted' safely into a java.lang.Runnable > SAM, requires lots of complex inference rules. This inference includes > the reasoning that returning something is compatible with returning > nothing, an inference that doesn't occur anywhere else in java. E.g: > > #void(Integer a) = #(Number a) (a); > > is legal. If you throw enough generics in the mix, the errors are > going to balloon into gobbledygook. Nevertheless, SAMs are what > today's java libraries run on, so any closure proposal that cannot > 'autobox' themselves into a SAM type would be even worse. > > "this" in a closure refers to the closure object. This seems nuts but > has been added for the benefit of allowing closures to recurse into > themselves. However, you'd get an endless loop when trying to infer > return type if you actually returned 'this', so the following is > explicitly defined as a compiler error: > > Object closure = #() (this); //Infer the return type on this miracle! > > The actual way closure types are created most likely will involve > generics of some sort, so arrays of closure types, like so: > > #()[] = new #()[10]; > > aren't legal for the same reason you can't write new T[10]; > > Link:http://mail.openjdk.java.net/pipermail/lambda-dev/attachments/2010021... > > On May 31, 8:07 am, Mark Derricutt <[email protected]> wrote: > > > > > > > I realllllly don't like the look of them. If they'd reused { } around the > > actual method call I'd be much happier. But reusing ()? > > > -- > > Pull me down under... > > > On Mon, May 31, 2010 at 5:58 PM, Michael Neale > > <[email protected]>wrote: > > > >http://www.baptiste-wicht.com/2010/05/oracle-pushes-a-first-version-o... > > > > I guess most of the attention has been on the semantics (and rightly > > > so) but wow... just wow. > > > > (sorry to interupt the appleposse with java news). > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "The Java Posse" group. > > > To post to this group, send email to [email protected]. > > > To unsubscribe from this group, send email to > > > [email protected]<javaposse%2bunsubscr...@googlegroups > > > .com> > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/javaposse?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group > athttp://groups.google.com/group/javaposse?hl=en. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
