Reusable and replaceable compiler parts

[Stephen J. McConnell]

Leszek:

I agree with argument and I think the work going on under the 294 and 277
JSRs (under the Module Project) [1] will have an important role to play in
this subject.  

However - I must also note that the javac compiler falls into that grey area
of bootstrapping the solution and being a part of the solution.  Assuming
the modularization activities pull together as a formal part of the SE7, I
figure that the sort of customization you are suggesting will fall into the
feasible spectrum (but 294/277 inclusion will be a prerequisite).

Cheers, Steve.

[1] OpenJDK Module Project
http://openjdk.java.net/projects/modules/




-----Original Message-----
From: compiler-dev-bounces at openjdk.java.net
[mailto:compiler-dev-bounces at openjdk.java.net] On Behalf Of
leszekp at Safe-mail.net
Sent: Monday, 20 August 2007 9:49 PM
To: compiler-dev at openjdk.java.net
Subject: Reusable and replaceable compiler parts

Hello

A "classic" compiler, javac more or less too, is composed of a few parts:
- lexer (scanner)
- parser
- semantic checker - in javac it is done by tree walkers
- optimizer, tree transformer, etc
- code generator

If an api to above parts/modules existed they might be reused separately.
Possible uses are in example:

- replace lexer and parser by other ones. This way various frontends may
be constructed, in example ruby, python, scripting languages etc
- bypass parser, directly construct abstract syntex tree, may be used
by a jsp compiler
- replace backend, output to another language instead of bytecodes

Of course an interface to compiler parts should be standarized somehow.
Abstract syntax trees probably should be modelled less around java syntax
and more around jvm operations. I think modularization it's the future of
compiler tools in general as there will be more and more demand for
domain specific languages.

Leszek Piotrowicz