On Thu, Dec 17, 2009 at 3:19 PM, Jochen Theodorou <[email protected]> wrote:
> We can try. I think a common approach would serve a high purpose in the
> matter that type inferencing could be done on a higher level and there
> are different ways to this as well. If you want to, we can try using the
> Groovy compiler for the cannibalization. It would me for Groovy 2.0, in
> which I want to do a big rewrite of many parts anyway. But the AST we
> use is quite complex and the design is not best in all parts. So maybe
> there is a better AST out there. At last with the Groovy AST I know how
> to do things ;)
I'm not even sure a common AST is required. Maybe I'm not making
myself clear enough?
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).
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.
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.
- 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.
