@David

Interesting notes about scalac in trunk/ I’ll have to build myself a copy and give it a try. What’s really interesting about this solution is it basically implements Adrian’s idea of a linker of sorts. It also solves probably the biggest problem with joint compilation, which is having to reimplement an already well-vetted compiler.

The problem is that this still isn’t a very general solution: it only works for Scala and Java. Groovy and the rest are still left out in the cold. Granted, it would be possible to build such a “stub generator” for Groovy as well as Java, but then what about users who want to go the other way? More and more these days, people want to “mix and match” their languages. I’m almost completely convinced that the only way to accommodate this need is with a generic framework. This framework *could* be based on the generation of stubs and compiler delegation, but why not go all-in and make every compilation process potentially-joint?

@Vidar

Yeah, language designers are quite the rebellious lot. I suppose I had never thought about it before, but it makes sense. After all, why would you create your own language if you didn’t already have a bit of a non-conformist streak?

The thing is, I’m really not sure if there’s much of a choice in this matter. Whether we go with a framework like I have outlined, or some other (preferably better) solution, it doesn’t matter. We really need to have some sort of interplay between the different compilers, otherwise would-be adopters are going to be permanently tearing their collective hair out over the pain involved. You’re quite correct that it is a difficult problem to solve. If all of the JVM languages shared a common paradigm then perhaps it would be simpler, but we have to be a bit more flexible than that.

The good news is that some of the smartest people in the entire development community are involved in language design these days. I have every confidence in their ability to come up with something extraordinarily clever to solve this issue. It’s probably just a matter of them recognizing that the need exists.

@Richard

You’re right that *object-oriented* languages can avoid circular dependencies by abstracting out a common superclass and thus breaking the dependent chain. However, this is a *lot* more work and it often feels unnaturally contrived. Furthermore, not every JVM language sports object-oriented constructs. Clojure (for example) is pure-functional. A circular dependency could be solved as long as a maximum of one of the languages involved is non-OO. After that point, such a solution breaks down.

@Andres

I actually haven’t tried Groovy’s generics at all, I was simply parroting what I’ve heard others say. Actually, I think it was Danno himself that mentioned having troubles with Groovy and generics, but it would have been some time ago. Hmm…

I looked around for any compiler-related JSRs, but only found the Java 6 compiler API (JSR 299 or something like that). That’s just a mechanism for interacting with the compiler programmatically, it’s not really a *compiler* framework, designed for use in the construction of compilers. To which JSR were you referring?

The Da Vinci Machine conference would be fun, but I’m afraid there’s just no way I could attend. However, if someone else thinks the idea is worthy of theft and re-presentation, I have no objections! I think everyone would benefit if *some* solution to this problem were to be proposed.

Does eclipse define such APIs for JDT?

What you describe here is called the joint-compiler, funny you talk about Java+Groovy+Scala compiler, Danno Ferrin (a.k.a. @shemnon) pitched the same idea ta JavaOne =) I believe there is already a compiler framework JSR (not exactly the fastest way to have it done), but it makes total sense (at least to me) to have a common ground to compile JVM languages together in a “single step”. Why not propose this topic to the upcoming DaVinci VM conference?

You can create multi-language assemblies by building “modules” and then merging them, but IIRC you have the same inability to have circular references between different modules.

But then how often do you really have such circular dependencies that cannot be broken by having Canvas (for example) dependent on RectangleBase and CircleBase rather than their concrete implementations.

But even on the JVM, part of the problem will be that language architects deep down tend to be anarchists – just look at the sheer number of parser generators. Sometimes it seems there are more parser generators than languages, since most serious language designers tends to write his/her own sooner or later, and often more than one, because so many of us hate the existing tools with a vengeance (I certainly do, including my own, so I keep striving for something nicer).

GCC sort of gets there. LLVM might also sort of get there. But they are complex beasts, and making it possible to support multiple languages with them pages it harder to keep them lean.

But frankly you don’t NEED a common compiler framework. All you need are a few narrow standardized interfaces to encapsulate calling a compiler, manipulating the resulting bytecode, and to query the classes. Java already have a lot of reflection support, so you’re sort-of halfway there.

Libraries for some things like emitting bytecode could certainly be reused, though, but even there you’re likely to run into vastly different philosophies on what the right way to do it is between compiler implementors.

Vidar

I’m pretty sure there is no problem mixing vb.net and C#, but of course they were both developed knowing they would be mixed/

Languages like IronPython and the like would have the same problem then?