generic type support
C. van Reeuwijk
Mon Feb 24 12:50:00 GMT 2003
> >>>>> "Andrew" == Andrew Haley <email@example.com> writes:
> Andrew> I was thinking of writing a parser from scratch.
> I've been thinking about that too.
> I've also thought about kidnapping Mark Mitchell and hypnotizing him
> to prefer Java to C++.
> Andrew> However, after the reception the new C++ parser received, I'm
> Andrew> not sure. In particular, accurate diagnostic messages and
> Andrew> good error recovery are tricky to get right, and any reduction
> Andrew> in the quality of error messages would be treated as a
> Andrew> regression, even if the perser was otherwise much better.
> In our case, it seems like improved correctness would trump that.
> Plus, it's a low bar to start with. There have been multiple PRs
> where gcj would ICE while trying to print an error message. I think
> there is one like that open right now. As long as we can flush stderr
> before crashing, we're ahead of the game. :-)
Since you're so negative about your current frontend, you may want to
take a look at the parser and frontend I did for my own static compiler
for a superset of Java. It is contains a clean yacc parser for
Java 2 1.4.
Although the compiler compiles a superset of Java, the extensions are
only enabled for files with the special extension `.spar'. For .java
files it is a quite compiant Java compiler. At one point in time it had a
better score for the Jacks validation suite than Sun's own compiler(!).
Unfortunately, after that the Jacks people added lots of tests for all
those stupid restrictions on inner classes, and I couldn't be bothered
to keep up.
Performance was never much of a problem; the compiler generates
C++ code, and the compilation of the C++ code (using g++) is by far
the slowest part of the whole compilation.
Kees van Reeuwijk, Delft University of Technology
More information about the Java