On Wednesday, September 14, 2011 9:15:30 PM UTC-4, Ricky Clarkson wrote: > > 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.
This seems to be mixing things. Code inside an inner class certainly behaves exactly like all other code; specifically, you can define mutable variables and you can assign to these variables. So the typesystem inside the "closure" is exactly the same. Which in this case, makes inner classes even more broken, it would be cleaner if inner classes had been designed as a pure-functional subset of the language that couldn't do destructive assignments at all. See Guy Steele's comments about inner classes: http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg04044.html - Java was initially planned to have closures, including mutable capture, but that was cut from JDK 1.0 and when they introduced inner classes in 1.1, it didn't have mutable capture and the reason was just "users feared the performance cost" - maybe reasonable concern with JDK 1.0's VM with the crappiest GC ever, but an obsolete issue since HotSpot, not to mention that other language features already ignore any concerns (performance or other) of implicit allocations, like Steele points. Also, James Gosling referred to inner classes as an "uncomfortable compromise ... that didn't really solve any problems": http://blogs.oracle.com/jag/entry/closures. And a third "father of Java", Bill Joy, also wanted full support for closures since day one: http://www.blinkenlights.com/classiccmp/javaorigin.html TL;DR: The mutable capture limitation of inner classes was NOT introduced by design. Not one of the original Java designers are proud of inner classes. Any attempt to justify this limitation as something that makes sense with good language design principles, is rewriting history - "it's not a bug, it's a feature". A+ Osvaldo > > 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 view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/Fff1UZB3f5EJ. 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.
