javac: not just for java?

[Ted Neward]

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