javac: not just for java?

[Peter Ahé]

No thanks.  I do just fine without them :-)

Cheers,
Peter

On 5/24/07, Jonathan Gibbons <Jonathan.Gibbons at sun.com> wrote:
> Hmmm, XML literals, anyone?
>
> It would be interesting to see if we could leverage such an
> architecture if one were in place.
>
> -- Jon
>
>
> On May 23, 2007, at 9:44 AM, Peter B. Kessler wrote:
>
> > I was thinking this might be useful at another level: for
> > multi-language files with small embedded languages.  E.g.,
> > if I have SQL constants in my Java code, why shouldn't I
> > have to leave the interpretation of that to runtime?  Why
> > can't an SQL compiler jump in at compile time and produce
> > bytecode, runtime calls, etc.?  An easy case might be
> > compiling regular expressions at compile time, rather
> > than wasting runtime on that.
> >
> >                       ... peter
> >
> > 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
> >
>
>