On Mon, Dec 21, 2009 at 6:43 AM, Rich Hickey <[email protected]> wrote: > 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.
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? > 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. 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: * 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. 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?) 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? - Charlie > >> 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. > > > -- 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.
