Per Bothner wrote: > On 12/17/2009 09:02 AM, Charles Oliver Nutter wrote: >> I may be naive, but what we really want here is simply a set of common >> protocols for doing the following: >> >> * Requesting from a language what types and methods are provided by a >> set of source files >> * Providing to a language services to look up types from other languages > > To handle dependency cycles or unknown dependies one can use a "compile > for export" option. This just generates a stub .class file, that > contains no code, or private fields, or anything else that is not > part of the "public contract" of the module. The key is that it > should be possible to generate this without reading any other > class files, and so cycles or other dependencies aren't a problem.
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. > > Generating the stub for Java is in theory easy: You can generate > stub method bodies by replacing all method bodies by "return null" > or whatever is appropriate for the method's return type, and > otherwise not checking for type compatibility and so. Why bother? Why not just stop once you've parsed enough to know the classes & methods, and return some representation of those? > There are some complications: one is that import-on-depend does need > to search for other classes. So you need one extra step, as below. > > So the multi-language compiler-driver does: > (1) Figure out the set of source files to (possibly) compile. > (2) For each source file, figure out the compiler to use, presumably > using extensions, though it could also use mime-types or looking at > the source file itself or some property datebase. > (3) For each source file, ask its compiler the set of class names > it might generate, using some to-be-specified simple protocol. Agreed. > (4) For each source file, compile it "for export". I.e. generate > the stub .classes mentioned above, leaving them in some temporary > location (ideally a "MemoryFileSystem"). > (5) For each source file, compile it for real, setting up the class > path to search the above temporary location first. When it needs to > import definitions from another file or class, it just reads the > sub class in "the normal way". The compiler should have access to > the map generated in (3), and should have a mechanism to invoke > the corresponding compiler "out of order". For example, a Scheme > library may want to execute a macro at compile time, and that > macro may depend on methods in some other class; thus it would > be nice to have a "compile this file first" mechanism. > > This approach still means an API invoking compilers with various > options, but we don't need to invent a protocol for representing > types and modules - we just use the .class files. 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. 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. Best, Martin -- 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.
