[email protected] a écrit : > Selon Ben Evans <[email protected]>: > > >> On Thu, Nov 26, 2009 at 9:29 PM, Tom Davies <[email protected]> wrote: >> >> >>> On Nov 27, 1:45 am, [email protected] wrote: >>> >>>> - the "invokedynamic" instruction is a must-have for reasonable >>>> implementations of "dynamic" languages, but "functional" languages >>>> will also leverage its power to implement closures far more >>>> >>> efficiently. >>> >>> Could you explain more about that, Xavier? >>> > > In fact, two different ideas were merged into this bullet point: > one is related to the "invokedynamic" instruction per se, while > the other one is related to the support provided for it. > > Concerning the support, current builds of JDK7 propose a "java.dyn" > package that provides not only method handles but also out-of-the-box > support for partial application of methods. As of today, it seems that > code generators for functional languages overcome the lack of method > handles by either using reflection, or generating many small classes. > The first solution is slow while the second one is cumbersome. > Method handles will therefore make things faster and more elegant. > > Concerning the instruction itself, my understanding is that it may > open the door to optimizations that are quite difficult to encode today. > I am indeed wondering if it may be a convenient way to implement > monomorphization: instead if using "invokevirtual" or "invokestatic", > one may use "invokedynamic" to dispatch to the implementation specialized > for a specific type in order to avoid paying the price of polymorphism. > This is just a wild guest, and would be glad to hear others' read on this > idea. > > > >> I think this might be a good time to reference Mark Reinhold's blog post >> about closures for Java: >> >> http://blogs.sun.com/mr/entry/closures >> > > This is indeed an interesting article but, as outlined in some comments, > those are not "closures" (at least from the standpoint of a functional > programmer). >
[...] > The blog entry does not give many details, but the unability to capture > (non-final ?) variables is against the tradition of what is usually referred > to as "closures". It is presented as a safeguard, but I think that people > that get accustomed to closures are indeed aware of the incurred danger and > are willing to pay the price as it comes with greater expressivity. > 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 :) > > Xavier Clerc > 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.
