javac: not just for java?

[Peter Ahé]

I think Ted is on to something.  If this is just to manage a shared
code-base that supports both .java and .ksl files from different
command, then I do not see the need to add a language object to
context.  However, if you want to create a multilingual compiler (mlc)
that can compile both files at once, perhaps it makes sense:

  mlc MyClass.java MyOtherClass.ksl CoolClass.scala

The trick would be to get all these files entered at the same time, so
they can all have mutual references.

Cheers,
Peter

On 5/22/07, Ted Neward <ted at tedneward.com> wrote:
> Would this be just trying to keep different compilers around in memory for
> different compilation runs, or are you trying to allow for multiple
> compilers being invoked as part of one compilation pass? The former would
> seem MUCH more approachable than the latter....
>
> Ted Neward
> Java, .NET, XML Services
> Consulting, Teaching, Speaking, Writing
> http://www.tedneward.com
>
> > -----Original Message-----
> > From: compiler-dev-bounces at openjdk.java.net [mailto:compiler-dev-
> > bounces at openjdk.java.net] On Behalf Of Jonathan Gibbons
> > Sent: Monday, May 21, 2007 10:32 PM
> > To: compiler-dev at openjdk.java.net
> > Subject: javac: not just for java?
> >
> > OK, here's the wacky thought for the day ...
> >
> > With KSL, you can experiment with your own "wacky" language features.
> > Except that that if they're wacky you can't call it Java. But if you
> > are still targeting the JVM, wouldn't you want to be able to mix n
> > match Java code and your wacky language, assuming they were
> > sufficiently interoperable.
> >
> > OK, so the premise might be a bit contrived, but assume it for now ...
> >
> > What would it take to mix n match "sufficiently similar" languages in
> > javac?
> >
> > Internally, javac is divided into a number of components,, such as
> > the scanner (or lexer), the parser, "enter" and "member-enter",
> > "attr", "flow", and so on all the way through to "gen". These
> > components can be divided into two groups, according to whether they
> > are language specific or not. Informally, if the components come from
> > the "parser" or "comp" packages, that means they are very specific to
> > the Java language. If they come from "code" or "jvm", they are closer
> > to the JVM.
> >
> > Currently these components are held as singletons in the Context
> > object.  But imagine if we introduced a new Language object, that
> > contained the language specific components, and then could put a
> > number of Language objects in the context, indexed by a Language
> > Kind, possibly derived from the filename extension of a source file.
> > (This would need to be expressed in JSR199 terms for the
> > JavaFileManager of course.) So then, when javac goes to parse a file,
> > it uses the file extension to determine a Language object from which
> > it can get a Scanner and Parser. The result would be an object that
> > could be processed through the rest of the compiler's pipeline, using
> > language-specific components as needed, and using language
> > independent components for the types and symbols, and eventually
> > gen.  If the languages are sufficiently similar or compatible (no-TM)
> > with Java, it should be able to define how such source files could
> > interoperate with Java source files, and be compiled alongside them.
> >
> > This is clearly just a wacky idea, barely half-baked, and we would
> > have to resolve issues like locating source files on the source path
> > for missing class files.  And the javac spec purists might grumble
> > and we'd have to call it something else (kslc, anyone?) but it might
> > prove a way to mix n match KSL variants with real Java code.
> >
> > -- Jon G
> >
> >
> >
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 5/21/2007
> > 2:01 PM
> >
>
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 5/21/2007
> 2:01 PM
>
>
>