On Mon, Dec 21, 2009 at 5:25 PM, Rich Hickey <[email protected]> wrote: >> Eventually a shared compiler has to work with some API against some >> "data" to coordinate different languages and the types they consume or >> produce. Whether that data comes from class files (a common format) or >> just appears to the coordinator as a set of interface-implementing >> datatypes (backed by per-language data), I don't care. > > But it's not just the coordinator, it's also the consumers (other > compilers). And we already know how to consume type information from > class files. > >> But as the >> inference case shows, it is not always possible to generate stubs in a >> single shot. >> > > When, how, with what granularity, and how often to generate type > information seems to me orthogonal to how that information is > represented. Is there any evidence that the javax.lang representation > is more suitable for languages with type inference?
I don't know yet :) I don't know whether the inference case is a requirement. I don't know whether the fine-grained online reflective querying of type information from arbitrary languages' files is a requirement. I'm exploring options. >> If your claim is that we can just have all languages generate stub >> classes, point all languages at the stub classes, and have them >> regenerate real classes...then I think you're wrong. > > That isn't my claim. I am just saying, when you are generating Java > type information, class files are a lingua franca. A lingua franca, yes, but a cumbersome one to deal with if your goal is to do more than just suck in source files and spit out class files. I'm interested in that simple case, certainly, but I am also interested in the possibility of a richer API for per-language compilers that might make it possible for IDEs (as an example) to see across languages. You could probably do some of that with stubs, but it seems like it would require regenerating stubs on every save, rather than simply re-requesting javax.lang representations for a file or subset of a file. Can you point us toward the code in Clojure that handles compiling circular references in generated Java classes? >> James Iry's case >> of type inference in Scala shows that much, since the return type of a >> given method (which you would need to put in the stub) depends on the >> return value of some other method (which may not be available at >> stub-generation time or which may have circular dependencies). >> > > I fail to see how stubs vs javax.lang affects this. If you are going > to have difficulty producing a stub you'll have difficulty producing a > javax.lang descriptor as well. Except that you don't have to produce the javax.lang descriptor all at once, like you do with the class files. The method declarations could be generated lazily: 1. Ask all languages what class declarations they provide 2. Ask all languages what types they need to consume to proceed with determining their method declarations, and presumably have the type information available 3. Ask the languages to proceed with producing method declarations based on the now-available set of types And at some point after this, each language will ideally have resolved all types it needs for its class/method declarations and can proceed to generate the final class format. Again, just a napkin sketch of how this might work. I will grant that any initial work on a joint compiler would be well-served by basing type discovery on class files and generated stubs, since that's the simple case and it covers common usage. > So we're going to build some dynamic network of compilers cooperating > to figure things out? I don't think that's covered by javax.lang. The > multiple type-inferring languages problem seems like a research topic > to me. Yes, it may be. It may also be a useful discussion to have here, and there may be aspects that apply to practical concerns (like IDE support for type knowledge across multiple languages' sources). Don't get too hung up on javax.lang as being the only potential API either. This is an open discussion about the features, challenges, and possible solutions for joint compiling multiple JVM languages at the same time. >> It's an API to data. The format is behind the scenes is irrelevant as >> far as the API is concerned. Isn't that the point of such an API? >> > > Except that everyone has to implement that API when they already know > how to deal with at least one format for the data already. APIs are > different from data - we might interact with XML via a DOM API but we > don't build systems by connecting their DOMs to each other. Going > through a static data representation allows us to decouple execution. > > Let's say you use javax.lang in the coordinator, and it asks a > compiler 'do you have type X.Y.Z in this file?' and it says 'yes', and > the coordinator asks for the type info and the compiler gives it a > javax.lang thingy. Now what? How does the coordinator convey that to > any other compilers? It's not data, it's a live object in the > coordinator process. Perhaps I didn't describe this well enough in earlier emails. The coordinator would basically get two things from the language compilers: 1. What types and methods do you provide (perhaps in separate phases) 2. What types and methods do you consume (again, perhaps in separate phases) The coordinator does as much or as little as is necessary to ensure the consumed types match up with the provided types, which could certainly mean triggering stubs to generate if necessary. The language compilers could upcall into the coordinator to ask for information on types they hope to consume, with the coordinator providing that type information (potentially without ever generating stubs) by just using the information it has gathered from other languages (and yes, from real class and jar files already on disk). And the language-specific compiler bits wouldn't necessarily even have to be reimplemented for each language if generating stubs would be enough for a given language. In that case, there could be a base "StubbedClassDeclaration" that knows how to ask a language to generate its stubs and reflectively inspect them. - 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.
