On Sun, Dec 20, 2009 at 8:28 PM, Per Bothner <[email protected]> wrote: > The problem is picking a representation. A .class file is one valid > well-understood representation. An API might be better, but designing > one for multiple languages is probably not feasible. (Remember CORBA.) > > I think the best choice for an API may be javax.lang.model.*. > It very Java-centric, but that's probably the best we can do. > It has the big advantage that javac already implements it.
I was actually thinking along the lines of the mirror API that the Annotation Processing Tool uses: http://java.sun.com/j2se/1.5.0/docs/guide/apt/mirror/overview-summary.html Again, I may be naïve but it seems to me we could easily form a common mirror type system that we'd feed to the orchestration logic. Starting with the mirror API would be pretty easy, since it's basically *all* interfaces. Going back to the example I gave Jochen: class MyClass < my.package.Foo def foo(a: java.lang.String, b: my.package.Bar) ... end end This script would produce a ClassDeclaration for MyClass, with a ClassType referencing (symbolically) my.package.Foo. We'd be providing MyClass, and the compiler would see that we're consuming my.package.Foo and look for a declaration elsewhere. Our MyClass ClassDeclaration would provide one method "foo" with two ParameterDeclarations point at ClassTypes for java.lang.String and my.package.Bar. The compiler would see these and add them to the list of produced and consumed types. I'll see if I can mock up a prototype over the holidays, or at least a compiler plugin for JRuby that can produce these interfaces. - Charlie >> True, this approach saves compiler writers from figuring out another >> representation for types and modules. However, compiler writers already >> need such a representation, e.g. if a single Groovy file contains >> classes A and B, and A refers to B and vice versa. Groovy has a >> ClassNode, and distinguishes between primary ClassNodes (that the >> compiler is compiling) and wrapper ClassNodes that wrap a java.lang.Class. > > Indeed. Kawa uses gnu.bytecode.ClassType for the same. > > The problem is we all have *different* representations, so that does > not help with inter-language interoperability. And unless you get javac > to implement the same representation, you have a problem: A JVM lingua > franca not supported by Java has limited use ... > >> Also, this approach makes extra work for compiler writers in generating >> a .class stub. Charlie is proposing a common lingua franca for these >> representations of classes, so we don't have to generate the stub. > > I won't help my breath, but look forward to it. > > I think an API that builds on (extends) javax.lang.model may make sense, > since that means interoperating with javac. > -- > --Per Bothner > [email protected] http://per.bothner.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. > > > -- 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.
