JVM Languages Google Group

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

2009-12-22T11:07:03Z

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?

2009-12-22T00:14:13Z

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?

2009-12-21T23:25:03Z

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?

2009-12-21T22:58:39Z

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?

2009-12-21T22:23:01Z

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?

2009-12-21T20:54:24Z

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?

2009-12-21T20:52:31Z

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?

2009-12-21T20:24:56Z

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?

2009-12-21T18:50:13Z

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?

2009-12-21T18:39:46Z

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?

2009-12-21T15:21:07Z

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?

2009-12-21T15:20:16Z

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?

2009-12-21T12:43:21Z

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?

2009-12-21T12:34:01Z

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?

2009-12-21T09:56:53Z

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