Charles Oliver Nutter schrieb: > Jochen Theodorou wrote: >> groovyc can compile java and groovy files in most cases. So it is no >> long way off > > Correct me if I'm wrong, but the joint compilation in groovyc doesn't > actually compile both at the same time; it compiles stubs for the Groovy > code so the Java code will compile (using javac) and then goes back and > compiles the Groovy code (using groovyc). That's not a single compiler > handling two languages, as is the case with JavaFX/Java using the same > backend (once you deliver a Java AST).
depends on how you define "at the same time". gmaven goes a different way here, but groovyc creates the initial AST for all groovy files, then uses that to create the stub and calls javac from within the groovy compiler. After this the groovy compiler resumes his work on the AST. Transforming the Groovy ast into a Java ast is imho impossible without doing almost all of the ast transformations we already do. But what is the benefit of just using the bytecode generation part of javac? they would use the same backend then, true. but imho this is not really different from what we already have when it comes to "at the same time". We would also have to always try to trick the javac checks, for example when not handling checked exceptions. Or Our Groovy Closures. We would have to get almost to just before the bytecode generation part. We would have to resolve the variable scopes by ourselfs, tell the compiler about what are classes and what may be classes, learn the compiler that a class names as it appears in the source code, might not be the real class name, because a import used a class renaming rule... and so on. The other way would be to let groovyc learn to compile java itself. I would see a much better chance there, because the groovy compiler is much more flexible... especially since I can change the groovy compiler, but not the java compiler. If I would build a multilanguage compiler, then such a compiler would be more like a framework. The "only" real problem it has to solve is one compiler part for language X asking the compiler part for language Y and the part for language Z if they can make this name into a class and give me the details (methods/fields/interfaces/superclasses) of that class. The problem then consists of the order in which I ask the language, what I do if multiple modules can handle that and to get that compiler part in a state where it can actually tell me about methods/fields/interfaces/superclasses complete with names, types and such.... well method bodies do not need to be compiled yet of course. I think the multiphase (different source units may have different phases completed) of the groovy compiler looks like a good base for that, but I think the compiler actually would need much less phases as he current groovy compiler and instead let the compiler parts use additional phases if they need it. Maybe I should just take the time and write the infrastructure and then talk to the java compiler people as well as for example to the scala, javafx and clojure people to write plugins, maybe even making that their default. as for JRuby... not sure what the JRuby compiler produces for a precompilation. I would keep such a framework extremely small, as I would not provide anything that deals with the ASTs. Of course an additional library could do that to make the creation of compilers more easy, but I am not sure that is really the case. Because the AST often implies certain things for the language... for example what structures do exist. You can always use less, but not more. And fitting all needs doesn't sound like a small framework to me ;) anyway... that is not what a IDE needs. The IDE needs a source interpretation so it understands what a comment is, from where to where a method goes and what variable this name does access. That is much more than a multilanguage compiler has to solve. bye blackdrag -- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to jvm-languages@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
