non-local returns and control flow in general are 'out' - they have been explicitly excluded from the scope of project lambda.
However, the ability of whatever proposal makes it to be expanded later to support of course isn't, and this is in fact a (minor) aspect of the closure debates - how much do we paint ourselves into a corner if we adapt closure proposal X? On May 25, 4:27 pm, Viktor Klang <viktor.kl...@gmail.com> wrote: > I also want to add the debate regarding non-local returns. > > On Tue, May 25, 2010 at 4:24 PM, Reinier Zwitserloot > <reini...@gmail.com>wrote: > > > > > > > I got the impression from Dick's note on the closure debate, as well > > as the response from the black hat guy, that there's some confusion > > about the closure debates. Yes, that's plural. > > > There's the: "Should Java have closures" debate. This debate is > > basically over. Mark Reinhold wants it, and convinced enough people > > within sun (before the oracle take-over). I doubt this will be back- > > pedalled now. > > > There's also the: What should it LOOK LIKE debate. This is a complex > > debate that hits on a gigantic amount of issues, simply because there > > are a bajillion ways to fit the following requirement set, and not one > > of them is the obvious right answer: > > > 1) Make it simple to write block-like constructs in java (simpler > > than it is now, at any rate) > > 2) Make sure whatever construct you come up with makes Parallel > > Arrays nice too (required use case) > > 3) Make sure whatever syntax you come up with is invalid if compiled > > with javac 1.6, and that anything written for javac 1.6 does not > > change in meaning. (backwards compatibility) > > > There are a bunch of issues which simply have no clear answer, so the > > debate on all of these is long, complicated, and involves massive > > introspection of existing java code as well as example "future" java > > code to see which makes for the better choice. The list is pretty much > > endless, so I'll just raise some of the major ones: > > > 1) The 'strawman' of Reinhold at Devoxx allowed something like > > "Closure foo = whatever; foo();" however, in java, unlike just about > > every other language with closures, methods and variables are separate > > namespaces. The above is mixing and matching them; "foo();" currently > > means: Invoke a method named 'foo'. It does not mean: Do something to > > a variable named foo. Should we break the separate namespace rule to > > make closures look more natural (but with a bevy of java puzzlers for > > when you have methods named foo as well as closure vars named foo - > > especially because of backwards compatibility), or should we move away > > form the strawman and use for example foo.invoke() or some other > > operator such as foo#() to 'run' a closure? Anyone who thinks there's > > a clear right answer to this is delusional. In practice there's an > > unclear right answer which is to move away from the strawman, as the > > effects of making 'someClosure();' work are quite large, and this is > > in fact the current status quo. The specific syntax for now is: "foo. > > ();" > > > 2) What should they look like? The strawman seems clear enough but > > has its problems when you nest closure types in closure types (param > > type of a closure is itself a closure) especially if some of the > > involved closure types throw exceptions. There's also some risk that 1 > > minor typo results in a baffling error message, as closure type > > declarations and closure block declarations look very very similar in > > the strawman. A lot of the discussion back in the BGGA / FCM / CICE > > days was in fact all about what it looks like, e.g. "I don't like the > > => thing in BGGA". > > > 3) How should it be implemented? Reifying the closure types is > > virtually impossible, as any closure proposal ought to work well with > > generics, which aren't reified, and there's no room in the agenda to > > try to reify generics. But without reified closure types, having > > arrays-of-closures becomes pretty much impossible, and you get the > > same erasure problems that generics have. There's some discussion on > > whether or not a form of reification can be added, though the > > conclusion so far seems to be: No. However, if reification isn't > > feasible, should closure types be added at all? The CICE proposal > > makes do without them. For ease of use with existing code, closure > > types will auto-convert themselves to "single-abstract-method > > interfaces" already, so with that feature, perhaps closure types > > aren't needed. Then again that gets annoying with very functionally > > oriented libraries. What to do, what to do ? > > > 4) There's also continued debate about time vs. completeness. Certain > > proposals are way more involved and are basically shot down due to > > lack of time, but those same proposals do seem to lead to better > > syntax and a more consistent language, though whether or not this is > > really true once such a proposal has been fully fleshed out is > > unclear, partly because there's not enough time to research it. Should > > java just get closures now, period, even if it won't be as good as it > > might have been, or should java either delay the release of java7 or > > move closures up to java8 to provide the time to get to the best > > possible proposal? > > > -- > > You received this message because you are subscribed to the Google Groups > > "The Java Posse" group. > > To post to this group, send email to javapo...@googlegroups.com. > > To unsubscribe from this group, send email to > > javaposse+unsubscr...@googlegroups.com<javaposse%2bunsubscr...@googlegroups > > .com> > > . > > For more options, visit this group at > >http://groups.google.com/group/javaposse?hl=en. > > -- > Viktor Klang > | "A complex system that works is invariably > | found to have evolved from a simple system > | that worked." - John Gall > > Akka - the Actor Kernel: Akkasource.org > Twttr: twitter.com/viktorklang > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to javapo...@googlegroups.com. > To unsubscribe from this group, send email to > javaposse+unsubscr...@googlegroups.com. > 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 javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
