javac: not just for java?

[Jonathan Gibbons]

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