Charles Oliver Nutter schrieb: [...] > I'm not even sure a common AST is required. Maybe I'm not making > myself clear enough?
but then what of the compiler you want to cannibalize? > The lingua franca for languages compiling together is a common set of > types they can use to collaborate through. In almost every case on the > JVM, that means we have to choose to present normal Java types to each > other (though in the future, we could present our own type systems, > but that's out of scope for this discussion). What I see as a common > compiler infrastructure is a set of mirror types (perhaps the same > ones used by the Annotation Processing Tool (apt) or by javac itself) > that all languages can produce and consume with their compiler > plugins. So for the following Ruby code: > > class MyClass < my.package.Foo > def foo(a: java.lang.String, b: my.package.Bar) > ... > end > end > > Compiling this would produce a mirror class called MyClass (provided > by this source) that extends a mirror class called my.package.Foo > (requested from the high-level compiler stuff). MyClass contains one > method foo (provided) that takes two arguments java.lang.String and > my.package.Bar (requested). for me that is part of the AST. oh well, ok, maybe our AST does represent a bit more than the bare program. Basically I understnad it so that you want to have a data structure that can represent the classes MyClass and Foo and in which MyClass will have a foo method with typed parameters. In Groovy this is done by ClassNode, MethodNode and Parameter. > Once all this has been resolved, the mirror types are used to generate > the bytecode for this code. There would be no exchanging of ASTs > necessary. but common data structures or else communication will be a problem. And that data structure could very well be part of the AST... so far my thinking. If it is not part of the AST, then you have kind of generate a second AST... or name it a communication data structure used to communicate between different language. For me the AST is already a communication data structure inside the compiler. > What I see as a high-level joint compiler is really a type-wrangler, > that can field requests for types from plugins and provide types to > plugins so that each language participating in compilation gets what > it needs (or else doesn't, and errors out). Then once everyone is > satisfied that existing libraries or other jointly-compiled code > provides all the types they need, they proceed to emit bytecode or > .class files. It's far simpler than having a shared AST or shared > nothing of per-language types...it's just a shared notion of Java > types and which Java types each language's source provides or > consumes. well ok, here comes into play that Groovy has in a static aspect almost the same type system as Java. Still... all that is needed is to write this communication protocol then, or not? 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 [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.
