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 as the inference case shows, it is not always possible to generate stubs in a single shot. >> Sure, I'm sure the generating dumb stubs can work, but it essentially >> means having to do almost the entire compile process twice for every >> language: >> > > Dumb stubs vs smart stubs? > > That doesn't follow. We will have to do precisely and just as much > work as is necessary to determine our types and method signatures, > then generate something (either a stub .class file, *or* an instance > of something implementing these javax interfaces, which in turn need > more instances of other interfaces, essentially forcing each of us to > duplicate the reflection API, ugh, why?) 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. 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). Stubs work great if everyone knows (at least symbolically) what types all their Java-facing types will return and receive, and can determine that based on existing on-disk or in-memory data. That's obvious, and that's how, for example, the Groovy joint compiler works (since it and Java do not infer return types in the way that Scala does). Is that all we want? >> * All languages generate stubs into a common location (possibly >> in-memory and combined with classpath) >> * All languages generate final code based on that common location >> >> 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. >> I don't really care much about the data format. Stub .class files are >> essentially just a richer and less flexible version of the >> mirror/javax.lang stuff, but certainly contain all the data we need >> (and potentially a lot of data we don't need...or can't generate >> without a full compile?) > > Really, I don't know what you are talking about. Generating a class > file is a simple thing for all of us to do, and we already do it. A > 'stub' classfile doesn't need anything other than fabricated returns. > There is no "potentially a lot of..." You are correct if, as stated previously, it's possible to generate stubs in isolation without a give-and-take mediation between languages. > 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? >> so they'd probably be fine for a simple first >> pass. But are you saying that having a common compiler infrastructure >> that actually speaks mirror interfaces rather than .class data >> *wouldn't* be good to have? >> > > I'm saying it would be premature to dismiss Per's suggestion with > hyperbole about *dumb* stubs and "a lot of xxx we don't need". There > is tremendous value in: > > an actual data format > that everyone already consumes > and everyone already produces I never dismissed it. Please don't put words in my mouth. I only suggested that what I had in mind was per-language impls of the mirror API. I know of the existing efforts that generate stubs, and I know that approach works well for the straightforward case. By "dumb" I didn't mean "stupid idea"...I meant "raw" or "simple" or "basic". Generating stub classes obviously can work as long as the participating languages are able to generate stubs without interacting with each other. And that may be enough for most use cases. But perhaps it's not enough to cover the cases that the current (for example) Scala/Java joint compiler is able to cover? > Being able to point a tool at some .class files and get a javax.lang > model would be great, but that should be a single job (if not done > already) we all could leverage, vs each of us having to implement > javax.lang interfaces, and programmatic access to same, directly. And if .class files are enough, I will happily concede that they're the best approach for the problem. Like I said...I don't care! Ultimately a joint compiler that knows how to work with all those .class files (or with a mirror API to language-specific data) and trigger a subsequent "complete" compile still needs to be there, which is the point of this thread. We're just brainstorming here :) - 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.
