On Dec 20, 8:37 pm, "Martin C. Martin" <[email protected]> wrote: > 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? >
Generating .class files isn't necessarily 'overkill'. I agree with Per, this is a standard representation. Given such .class files in the classpath, all of our existing compilers and tools will 'just work', right now. Reflection will work, etc. > > > (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. > In Clojure, when in such a situation, I generate stub classes in memory, just as Per describes, and for the same reason, everything downstream just works. > 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. > There is extra work in any case, as no one is yet generating what Charlie is proposing. Also, 'compiling with options' seems more amenable to implementation via ant et al, vs programmatic invocation of and interaction with compilers via an API. Rich -- 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.
