On 12/20/2009 05:37 PM, Martin C. Martin wrote:
>
> Per Bothner wrote:
>> To handle dependency cycles or unknown dependies one can use a "compile
>> for export" option. This just generates a stub .class file, ...
>
> Charlie's point is that generating a .class file is overkill. If we
> just need to know a list of types& methods, then we just need a
> function that takes source files and returns such a list. We don't need
> to go all the way to generating valid .class files.
>
> Why bother? Why not just stop once you've parsed enough to know the
> classes& methods, and return some representation of those?
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.
> 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.
