Hmm... If you didn't have to worry about Java <7 compatibility, for one thing with invokedynamic you could remove a lot of code from Clojure. No more IFn or AFn. You simply have a method handle.
Second, I think it would allow the JVM to have a better view into optimization, and would allow the JVM to optimize something speculatively and allow for Clojure tell the JVM when to deoptimize with a SwitchPoints and MutableCallSites. I don't think Phil's comparison is actually a fair one. If you're going to use type hints or type inference, then you're basically moving more towards static typing, which of course will be faster. If you're going to do dynamic dispatch without compile time types to aid the compiler, then invokedynamic is most certainly going to be faster than reflection, and make for much simpler code. I think invokedynamic would be great for Clojure. Of course there are other concerns like the fact that it is only for Java 7, so maybe it won't be the best place to put resources at the moment. But that's no reason that Tal can't work on it. Paul -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
