Le 27/11/2009 17:33, Alexandru Nedelcu a écrit : > On Fri, 2009-11-27 at 15:32 +0100, Rémi Forax wrote: > >> Perhaps the unability to capture (non-final ?) variables is against the >> tradition but the main >> use cases for closures in Java is the ability to express blocks of codes >> that will run in parallel. >> Multi-cores CPU are no more a wet dream :) >> > Hi, sorry to chip in, > > The problem in this case is probably the main use case, which is a > shortsighted one. > > It's generics with type-erasure (with the screwed use-site variance) all > over again. And I'm pretty sure the main use case for the current > generics implementation was covered, but now looking in retrospective, > was it really worth it? > > I am thinking about designing a new language on top of a subset of Java, > and assuming I go through with it, a closure in my language will be an > instance of an anonymous class that extends something like Func<TResult, > TVar1, TVar2...>. >
You should consider the use of MethodHandle, method handles are reified, not Func<...>. > If the type of the anonymous class is annotated with something like > @KeepSynTree, then the compiler will also assign to that class a > reference to the syntax tree of the function and a map with the captured > context (it's more or less what Linq does). > > In the context of parallel processing, a library designer could take > these syntax trees and rewrite them or transform them to something else. > > Imagine an ORM like LinqDB which transforms your closure into > conventional SQL, and then with only one change in your table model it > could work with a NoSQL storage that requires fork/join ... like the > storage used by FriendFeed which shards entries between multiple MySql > servers ... ( http://bret.appspot.com/entry/how-friendfeed-uses-mysql ) > ... which in the case of RANGE select would first do a query to the > relevant index, then it would issue async requests to all the servers > involved, and then would take the results and do further processing with > a fork/join algorithm that also offloads some workload to your GPUs. All > of this with the same syntax from the user's POV. > > I would like to see such features coming in Java in regards to > parallelism, rather than conservatism in regards to the handling of > non-finals. And unfortunately I have to implement my own compiler (I say > unfortunately, because while fun, I need them yesterday). > If you want to implement an expression tree. I've written a blog on how to implement that in Java (only the runtime part): http://weblogs.java.net/blog/2009/07/31/dlr-expression-tree-java Rémi -- You received this message because you are subscribed to the Google Groups "JVM Languages" 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/jvm-languages?hl=en.
