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). > I was fortunate enough to hear Mark speak about his ideas for Java closures > at Devoxx, and at the JDK7 BoF asked him about what was in his mind for > implementing them, and whether the implementation would be based around > method handles. > > Mark indicated that he hadn't thought much about implementation yet, but > that he didn't think that method handles were the most likely way to > implement closures for the Java langauge. Well, I don't know which exact semantics will be given to Java closures, and am not really aware of retrofit issues (i. e. how to make closures nicely interact with collections, event handlers, and the like) and hence cannot say if method handles would be a good implementation base. But, regarding functional languages my feeling is that to encode a closure we just want a structure with a code pointer and some values. A method handle will just be perfect to act as the code pointer. > It may be worth reading Mark's post carefully, as the behaviour he describes > for the closure structure he's describing seems to me to be somewhat > different from the closure behaviour seen in (some?) other languages, and > I'm not sure that the behaviour described for Java closures (Jclosures?) > really covers all use cases for closures present in dynamic languages. 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. Xavier Clerc -- 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.
