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...>. 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). -- 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.
