I think the problem is that whenever you start trying to make sure that all code wrapped in a lambda behaves the same as code not wrapped in a lambda (return, break, this, continue, throw all behaving the same way) you get into odd territory and someone picks up on it and reacts.
Scala actually does some* of what Gafter's original proposal did regarding control, and the reality is I've only ever noticed when I explicitly tested it to see if I could observe a NonLocalReturnException. However, I don't think we're going to win that fight, and C#'s level of lambda support really is a marked improvement over what we have in Java today. * some, because Scala doesn't have continue or break. -- Skype: ricky_clarkson On Wed, Sep 14, 2011 at 8:38 PM, opinali <[email protected]> wrote: > Hi clay, > > Ok let's be more formal now. I agree with option A below (instead of B); > "closure" is very well defined in numerous classic CS books as the pairing > between a function and an environment that provides bindings to its free > variables. The concept comes from lambda calculus where functions can only > exist in the form of functions, so I understand view B - but practical > programming languages are very distant from pure lambda calculus; only in > the Lisp family (I think) they are really the same because functions are > just sugar for a lambda - i.e. a function is a lambda that is bound by some > name to some environment. But there are many other languages, including > Java, where this doesn't happen, unless you interpret the concept of > "environment" as something more general, including the all scoping rules, > classloaders, etc. IMHO this is going a bit too far, I'm happy with a > definition of closures that does not depend from lambdas. > > Now back to my points 1/2, let's try to refine the discussion to its true > essentials: the major point of debate is whether Java's closures (with or > without Java 8's lambdas) are "good enough". So let's try to define what > constitutes good enough. I am a strong advocate of very powerful closures; I > was rooting for BGGA with its non-local returns, control abstractions..., > but I concede that these features are only necessary to extend Java's > paradigm, allowing significant new idioms. But it's fair to require for > "good enough", an implementation of closures that is at least sufficient to > get along with the *existing* language paradigm, idioms and other features > (typesystem, OO model etc.) - anything better that that is a bonus. If we > agree on this, then "good enough" boils down to orthogonality. And the > current support for closures (without capture of mutable variables) is > clearly NOT orthogonal, because destructive assignment is a HUGE part of the > Java language. No amount of fancy functional-esque frameworks or conventions > can change this simple fact. It's broken since JDK 1.1's introduction of > inner classes, and it will be broken in Java 8's even with lambdas, nice > syntax, and tons of new or retrofitted APIs to use closures/lambdas. > > A+ > Osvaldo > > > On Tuesday, September 13, 2011 7:58:02 PM UTC-4, clay wrote: >> >> From the best I can gather, the principle disagreement is definitions. >> There are three views in this thread: >> >> A) Java has closures. Closures, by definition, do not necessarily >> require lambdas or first class functions, which Java doesn't have. >> B) Closures, by definition require lambdas and/or first class >> functions, so since Java doesn't have those, it can't have closures. >> C) Pure closures, by definition, don't limit you to accessing only >> "final" variables, so the anonymous class functionality doesn't >> qualify as a closure. >> >> Osvaldo, >> >> Regarding point #1: First, I think you mean anonymous classes, not >> inner classes. Secondly, I'd stress that anonymous functions (lambdas) >> are a distinct feature from closures. A language can have one feature >> but not the other. Java has closures, but not lambdas. And I can't >> think of them off the top of my head, but I'm sure there are languages >> with lambdas that don't close over the defining environment, and >> therefore don't have closures. >> >> Regarding point #2: I'm not sure what you are getting at here. Sure, >> Java is behind the pack in terms of immutable programming and >> functional programming support, but you can use third party libraries >> like Functional Java and adopt that style as a programmer. Only a few >> languages like Haskell really force those concepts on you and >> guarantee safety from mutability issues. In Scala, immutable code and >> functional programming still requires programmer compliance and it's >> easy to write imperative mutable code. Regardless, this seems like a >> tangential issue. >> >> Kevin, >> >> I'm not arguing that Java has closures because you can achieve the >> same goals without real language level support. I'm arguing that >> closures are inner functions/methods that can access variables from >> the outer function/method scope, and the Java language syntax >> completely supports that. You are claiming that closures require >> lambdas by definition, and I disagree with you on that definition. >> Java doesn't have lambdas. Sure, you can achieve similar results with >> anonymous classes, but the Java language itself doesn't provide >> lambdas. >> > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/javaposse/-/53VocU4KYT0J. > > 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. > -- 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.
