javac: not just for java?

[James Gosling]

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

Oddly enough, javac once a similar feature.  The command line
parser would take the file extension and use that to index into a table
of objects.  It lived most of it's life in an off-to-the-side  
repository, but
was actually checked into the mainline briefly - but it got yanked
because of some bugs.

It was built by me for the Fortran front end I built: I was trying to
see just how weird a language the JVM and javac infrastructure
could support.  It actually worked very well.  I had most of BLAS
and LINPACK running when I threw it out (well...  I had to start
spending time on my real job).

Yes, you read right: Fortran.  I am sick and twisted.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20070526/bce7e776/attachment.html