On Dec 21, 3:54 pm, Charles Oliver Nutter <[email protected]> wrote: > Perhaps we should take a deep breath before proceeding. Ready? > > On Mon, Dec 21, 2009 at 2:24 PM, Rich Hickey <[email protected]> wrote: > > On Dec 21, 1:50 pm, Charles Oliver Nutter <[email protected]> wrote: > >> I'm not sure where reflection comes into this, unless you're referring > >> to one way the top-level compiler stuff would get class data (and > >> reflection may be a particularly poor way, since it has to *load* the > >> classes and requires that they be valid/complete to do so, rather than > >> just reading the data format). Generally we're talking about .class > >> data and Java-centric type structures across languages. What do you > >> need reflection for at compile time? > > > You are missing the point. .class file *are* a data format. And > > everything in the Java ecosystem understands them already. APIs *are > > not* a data format, they are a means for live communication between > > program entities. > > 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? > 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. > 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. > >> And we *still* need a coordinator since we all have different ways to > >> generate stubs or trigger a final compilation. > > > Yes. But with Per's suggestion, that process is significantly more > > decoupled, and allows for more reuse of existing capabilities. > > Sure, sounds great! I don't think I ever said it was wrong...just that > it may not cover necessary cases for the languages under discussion. > Specifically, Scala can't necessarily generate complete stubs without > some interaction with the other languages and their type definitions, > which could be as-yet-uncompiled. > 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. > > And again, javax.lang is not a data format. > > 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. 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.
