javac: not just for java?

[Peter Ahé]

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