javac: not just for java?

[Jonathan Gibbons]

Yes, that is a presumption here, based on the fact that the presumed  
languages are targeting the JVM in a reasonably sane manner.  If they  
don't share that, there is little point sharing the compilation.

-- Jon


On May 22, 2007, at 11:20 PM, Peter Ahé wrote:

> Sounds like an interesting approach and a fun project.  I guess it
> will be easier if all the languages can share the Symbol/Element
> protocol.
>
> Cheers,
> Peter
>
> On 5/22/07, Jonathan Gibbons <Jonathan.Gibbons at sun.com> wrote:
>> 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
>> >>
>> >>
>> >>
>>
>>