javac: not just for java?

[Jonathan Gibbons]

Yes, the thought is to be able to handle mutually referential source  
files on the
command line at the same time,, which is why we would have a Language  
object
yo abstract what it means to parse the files, enter the symbols, do  
semantic analysis,
and so on.

-- Jon G

On May 22, 2007, at 10:59 PM, Peter Ahé wrote:

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