javac: not just for java?
Jonathan Gibbons
Jonathan.Gibbons at Sun.COM
Tue May 22 23:15:37 PDT 2007
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
>>
>>
>>
More information about the compiler-dev
mailing list