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.
