On Tue, Jul 7, 2009 at 4:21 AM, rssh<[email protected]> wrote: > > Yet one potentially interesting areas for collaboration can be 'mixed > compilation for JVM', where we have set of sources in different > language (may be mutually dependable) and some 'meta-compiler' which > can generate code from different languages, calling compilers for > concrete languages. > As I know, now mixed compilation just work for groovy+java, scala + > java, and scala+groovy+java. > (http://groovyland.wordpress.com/2009/03/03/groovyscalajava/) > It would be great, to have standard API for compilers (as I > understand - with two operations: > (1.A) - generate 'definition' class files for given source file > (without resolving internal dependencies) > // or may be just publish dependency information in some form. > (1.B) - generate 'implementation' class files for given source file. > > I guess, (A) is possible not for all languages (for example - when we > want in X to reexport methods of Y, it is impossible to generate class > file for X, without compiling Y). > > So, questions are: > - are anybody also thinking about such possibility ? > - what can be potentially safe meta-compiler protocol ?
JRuby is very likely going to need a dual compiler soon, as we start adding more Java type capabilities. It may not, however, be as necessary as for Groovy, since most of JRuby's type-lookup logic can be deferred until actual runtime. In Groovy's case, I know they actually seek out the types you specify, so they need to be available during compilation. But is this a real requirement? All that's really needed in many cases is the package + class name for inserting into generated signatures. "Ljava/lang/String;" is enough to build a signature that takes String. There are certainly needs to be able to load annotations and enumerations, but it seems like the joint compilation needs there are greatly reduced. Joint compilation is also dependent on having some shared representation of types. In JRuby, we are going to be exploring how to bring Ruby and Java types closer together to make more integration scenarios possible (or simply easier than they are today). Ruby types currently are not represented in terms of Java types, so we'll need to consider whether we should do that or just have a separate compiler pass that is aware of Java types. We are working on the new compiler now. I'm definitely interested in joint compilation strategies, especially if we could do them in ways that support many languages without bootstrapping each compiler anew. - Charlie --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
