On Thu, Aug 30, 2012 at 9:55 AM, Ricky Clarkson <[email protected]> wrote: > BGGA was always overreaching(*) and likely to have things > removed/changed. Non-local breaks, continues, returns and throws, and > writes to non-final local variables would always be contentious. I > didn't mean to say that everything was ready in 2007, as there were > always more discussions to have, but there was quite a period of > apparent indecision on whether to have lambdas at all. I'm sure > without the period of indecision we'd have had them in Java 7, and in > quite a similar form to the current plan for Java 8, i.e., I'm not > sure we've collectively learned anything
Closures (and generics) were known to the team originally working on the language, but were left out for various reasons, including making release dates, etc. Advocacy for adding some form of fuller closures in Java from some people working on Java date all the way back to circa 1997: http://gbracha.blogspot.com/2008/06/incremental-development-environments.html?showComment=1212937440000#c5772865805884729418 BGGA and Neal's promotion of it several years back certainly can be credited with bringing a much greater awareness of closures to typical Java developers; although the need for closures was not universally acknowledged and there were fierce debates over the details of what could or should be added: http://www.parleys.com/#st=5&id=116&sl=1 Even today, there is still lots of traffic on lambda-dev even on minor syntactical points. Project Lambda has a superset of a subset of the features of BGGA; that is, based in part on looking at BGGA, fundamentally different design decisions were made in Lambda than in BGGA. For example, Lambda does not have function types. However, it is certainly true that Jigsaw was not the only JDK-related project impacted by Sun going out of business. > That's excellent about cooperation with IDE maintainers, I hadn't > realised that had happened. > > Joe, would you say that C#'s lambdas informed the Java design? I think it is fair to say both the C# and Java language teams keep on eye on what each other is doing. -Joe > > * BGGA's overreaching was because Neal Gafter wanted to make sure that > code within a closure meant exactly the same as code outside a > closure, down to a continue inside the closure being able to cause a > loop outside the closure to continue. It was, engineering-wise, a > very good solution, and I had lots of fun breaking that compiler while > it was in alpha, but I think everyone involved knew that a sample of > the features would be chosen. > > On Thu, Aug 30, 2012 at 1:37 PM, Joseph Darcy <[email protected]> wrote: >> On Thu, Aug 30, 2012 at 7:54 AM, Ricky Clarkson >> <[email protected]> wrote: >>> 0? It's already five years since the fully-working BGGA compiler for >>> lambdas and six years since the proposal. >> >> There are significant technical differences between the feature set of >> BGGA and the feature set of Lambda. As noted in the JEP for Lambda >> (http://openjdk.java.net/jeps/126): >> >> "Project Lambda started with a straw-man proposal and has gone through >> several "State of the Lambda" iterations which have evolved both the >> syntax and feature set of the project. >> >> The work on lambda expression portion of Project Lambda is informed by >> numerous previous efforts, including but not limited to: >> >> * BGGA, >> * CICE >> * FCM >> * Pizza [dates back to 1997 and predates the GJ work which was the >> basis for Java generics -ed.] >> >> The feature set of Project Lambda is judged to better address the >> needs of evolving the Java platform than the earlier proposals. >> >> The design of virtual extension methods is likewise informed by a >> large body of prior work in the programming language community >> including: >> >> * multiple inheritance in C++ >> * static extension methods in C# >> * traits in Fortress >> * traits in Scala >> * mixins in Strongtalk" >> >> There are active discussions about Project Lambda over on its OpenJDK >> mailing list. >> >> >10 years since MS added >>> delegates to their fork of Java (I don't mean C#, but the one the court case >>> was about) which are not lambdas but meet some of the same needs. >>> >>> I expect tooling support will be there before release, the IDEs had the Java >>> 7 features ready before it was released. Less maintained tools like jad or >>> some of the lint tools might not be ready on time though. >>> >>> Compare that to Java 5 though, where the IDEs were terrible on generics for >>> quite a while. I think that was because the process was more closed back >>> then. I don't like the slow speed of progress but I do appreciate that it's >>> at least visible from the outside. >> >> One reason there was prompt IDE support for Project Coin/JSR 334 >> features that the Project Coin/JSR 334 team made sure to reach out and >> work with people from all three major IDEs; more timely IDE support >> for the new language features than in JDK 5 was an explicitly >> recognized goal this time around. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "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. >> > > -- > You received this message because you are subscribed to the Google Groups > "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. > -- You received this message because you are subscribed to the Google Groups "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.
