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
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? * 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.
