JVM Languages Google Group

Re: [jvm-l] Re: Common compiler infrastructure?

fo...@univ-mlv.fr (Rémi Forax) — Tue, 22 Dec 2009 11:07:03 UT

Le 22/12/2009 00:25, Rich Hickey a �crit :
If you have a type representing a type variable, it is.
[...]
R�mi

Re: [jvm-l] Re: Common compiler infrastructure?

head...@headius.com (Charles Oliver Nutter) — Tue, 22 Dec 2009 00:14:13 UT

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.
A lingua franca, yes, but a cumbersome one to deal with if your goal

Re: Common compiler infrastructure?

richhic...@gmail.com (Rich Hickey) — Mon, 21 Dec 2009 23:25:03 UT

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.
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

Re: [jvm-l] Re: Common compiler infrastructure?

head...@headius.com (Charles Oliver Nutter) — Mon, 21 Dec 2009 22:58:39 UT

Sure, I agree with that. It's an outlier, in any case.
I think we need more than that: there's other non-Sun-javac Java
compilers out there, that would presumably want to participate. Maybe
we by presenting stubs we'll be good enough, but having a standard
interface for each language that can 1. generate stubs and 2. trigger

Re: [jvm-l] Re: Common compiler infrastructure?

p...@bothner.com (Per Bothner) — Mon, 21 Dec 2009 22:23:01 UT

If the return type of an exported method depends on type inference
and that inference may have circular cross-module dependencies,
my reaction is: Don't do that. You can't define a stable API
that way, at least not a library API. It might be OK for a
module-private method (in the sense of JSR-294 - i.e. a group of

Re: [jvm-l] Re: Common compiler infrastructure?

head...@headius.com (Charles Oliver Nutter) — Mon, 21 Dec 2009 20:54:24 UT

Perhaps we should take a deep breath before proceeding. Ready?
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

Re: [jvm-l] Re: Common compiler infrastructure?

johnwco...@gmail.com (John Cowan) — Mon, 21 Dec 2009 20:52:31 UT

I agree. Because my compiler is not (yet) self-hosting, I use "javap
-public" to get what I need out of .class files, so I definitely want
an offline way of getting information about classes I don't generate.
In any case, the issue of how to consume a remote class is not
trivial. I know how to consume Java classes and expose them, but

Re: Common compiler infrastructure?

richhic...@gmail.com (Rich Hickey) — Mon, 21 Dec 2009 20:24:56 UT

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.
Dumb stubs vs smart stubs?
That doesn't follow. We will have to do precisely and just as much

Re: [jvm-l] Re: Common compiler infrastructure?

head...@headius.com (Charles Oliver Nutter) — Mon, 21 Dec 2009 18:50:13 UT

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

Re: [jvm-l] Common compiler infrastructure?

head...@headius.com (Charles Oliver Nutter) — Mon, 21 Dec 2009 18:39:46 UT

Ok, now I see where the right bits go in the javax.lang stuff...I was
thrown off initially because there's far fewer interfaces, but they
appear to have been condensed a bit (ExecutableElement for all
method-like things, and so on). So using javax.lang plus a jarred-up
backport version of it would be just as good as apt, and javac would

Re: [jvm-l] Common compiler infrastructure?

james...@gmail.com (James Iry) — Mon, 21 Dec 2009 15:21:07 UT

This seems like a clean approach in general, but it needs some refinement to
deal with languages with type inference. As a simple example, a bit of
Scala code can say
class SomeScalaClass {
def foo(x : SomeNonScalaClass) = x.something()
The return type of foo depends on the return type of
SomeNonScalaClass#something. If that's the only dependency then compiling

Re: [jvm-l] Re: Common compiler infrastructure?

da...@drmaciver.com (David MacIver) — Mon, 21 Dec 2009 15:20:16 UT

2009/12/21 Rich Hickey <richhic...@gmail.com>:
One issue to bear in mind is that this potentially generates a lot of
stubs where it doesn't need to. With Scala at least the generation of
a large number of small class files is a big performance hit.
Potentially doubling the number generated (even if the version

Re: Common compiler infrastructure?

richhic...@gmail.com (Rich Hickey) — Mon, 21 Dec 2009 12:43:21 UT

On Dec 20, 8:37 pm, "Martin C. Martin" <mar...@martincmartin.com>
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.

Re: [jvm-l] Common compiler infrastructure?

j...@pagesmiths.com (Jim White) — Mon, 21 Dec 2009 12:34:01 UT

That private API has been replaced by the standard Java extension API
Per referred to (javax.annotation.processing.P rocessor processes
javax.lang.model.element.TypeE lements).
[link]
And as I said, if you want to do something like Groovy's unified

Re: [jvm-l] Common compiler infrastructure?

mi...@milessabin.com (Miles Sabin) — Mon, 21 Dec 2009 09:56:53 UT

On Mon, Dec 21, 2009 at 9:21 AM, Charles Oliver Nutter
I like the sound of this ... good choice :-)
Cheers,
Miles